OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] Groups - ICS-201-draft0.2.xsd uploaded

Yup, I was hoping that was what you meant.


At 3:03 PM -0500 4/1/04, R. Allen Wyke wrote:
>I don't disagree with what you are saying at all, but at the same 
>time let me give you a little history on the ICS form, which will 
>bring this into more clarity and describe more about why I sent the 
>ICS not only represents a method/structure for breaking into teams 
>during a response to an incident, but it also has de facto standard 
>forms that are used for various "things" during that response. The 
>201, for lack of a better phrase, is a situation status form/report. 
>Now, NIMS 
>(http://www.dhs.gov/interweb/assetlibrary/NIMS-90-web.pdf), which is 
>the result of HSPD-5 
>starts to take ICS from de facto to "standard" - at least within the 
>US Fed Gov. Ok, set that aside for a second. From our perspective, 
>the idea of sharing general incident information is certainly within 
>the scope of what this group was created for and a good number of us 
>have expressed a desire to share incident data. Even the work DMIS 
>is doing with their TIE (Tactical Information Exchange) is a method 
>of sharing incident data. But ahhh, here in-lies the issue.
>With NIMS stepping out and "standardizing" on ICS (which does not 
>automatically imply an XML representation of the forms btw), then it 
>is easy to see the interest in having a standard XML version of 
>such, but who (and who can) create that XML version/schema/whatever? 
>Are the NIMS authors/powers planning on doing this? Have they even 
>considered it? This is where my concern about the TC's approach 
>comes in. I feel we are stepping out of bounds to even think about 
>defining a schema for something we don't own. I think it might be a 
>better idea to push the powers that be that wrote/defined NIMS to 
>formalize a movement to do such, which may or may not include this 
>TC (or some of its members).
>Personal opinion aside, there has been interest in the group for us 
>doing this, as you can see peppered through our list archives over 
>the last year. The current status is a crack at an XSD, which Rex 
>posted. Inserting my own opinion again here, that still does not 
>feel right, but if it is the wish of the group and if we decide to 
>press on, then I would suggest something that represents a little 
>less parent feeling, hence the mention of XForms. Basically, let 
>NIMS "own" the definition of this ICS form, but if we need a 
>"profile" for our own use and we are determined to craft such, then 
>it might be a better idea to abstract the actual definition of the 
>form from our use of it. Enter XForms as a potential way to 
>accomplish such a task. That is all I am saying.
>Again, the jury is out for me on if and how we would want to engage 
>ourselves. I would defer to someone who has a stronger opinion of 
>whether we should even go down that path or not and how that would 
>play with the work at DHS for additional information, clarification, 
>and suggestions. Putting Chair hat back on, I just want to make sure 
>we are not sticking our nose where it ought not be, and if we are 
>that we are doing it in a collaborative and welcomed manner.
>On Apr 1, 2004, at 2:40 PM, Bullard, Claude L (Len) wrote:
>>I am saying don't normatively associate any spec with any other spec
>>unless you have to.  That's all.  Don't let me confuse you because
>>I don't have time to look into ICS.  I was responding to Rick
>>being uncomfortable with specifying XForms.
>>XForms is an explicit application language.  There are alternatives
>>to implementing XForms so you should be uncomfortable with that choice.
>>Is the process specification meant to be executable or
>>only an abstraction of a process that can be implemented
>>differently?  Do you *need* a process specification or is
>>it informative material provided to help other implementors?
>>Dare to do less in cases where doing more forces you to
>>make choices for the implementors that they can better
>>make for themselves.  Do more if the chances are good
>>that without the extra work, the specification can't
>>be implemented interoperably at all.  Be very certain
>>about interoperation:  systems interoperate; data is
>>portable.  So if you spec interoperations normatively
>>you are designing the system, not the data.
>>-----Original Message-----
>>From: R. Allen Wyke [mailto:emergency-tc@earthlink.net]
>>Sent: Thursday, April 01, 2004 1:33 PM
>>To: Bullard, Claude L (Len)
>>Cc: emergency@lists.oasis-open.org
>>Subject: Re: [emergency] Groups - ICS-201-draft0.2.xsd uploaded
>>Ok, so are you agreeing or disagreeing with what I proposed? It sounds
>>like you agree that we should not attempt to define an XSD (schema) for
>>ICS 201, but then you mention preparing a process spec and not address
>>the front end (GUI), which is what I *think* we can do with XForms. Or
>>are you saying that even touching this with a 10 foot pole (ie: XForms
>>too) is way to close?
>>Just wanting to make sure I am not misunderstanding. Personally, I
>>could go either way. I just know that I have a comfort issue with the
>>XSD. Jury is out on the XForms idea - it was just a thought that I felt
>>was better than defining an XSD.
>>On Apr 1, 2004, at 2:25 PM, Bullard, Claude L (Len) wrote:
>>>I agree with Rick.  Don't open liaisons or set dependencies
>>>on other specifications and standards unless absolutely necessary,
>>>meaning, your specification can't be used without them.
>>>1.  Your specification will be tied to the evolution of the
>>>     other specification, and
>>>2.  It might lose.
>R. Allen Wyke
>Chief Technology Officer
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]