Yup, I was hoping that was what you meant.
Ciao,
Rex
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
>email.
>
>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
>(http://www.whitehouse.gov/news/releases/2003/02/20030228-9.html),
>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.
>
>Allen
>
>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.
>>
>>len
>>
>>-----Original Message-----
>>From: R. Allen Wyke [mailto:]
>>Sent: Thursday, April 01, 2004 1:33 PM
>>To: Bullard, Claude L (Len)
>>Cc:
>>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.
>>>
>>>len
>>
>>
>--
>R. Allen Wyke
>Chief Technology Officer
>
>919.806.2440
>
>
>To unsubscribe from this mailing list (and be removed from the
>roster of the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email:
Tel: 510-849-2309
Fax: By Request
