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

[R. Allen Wyke <emergency-tc@earthlink.net>]

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: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.
>>
>> len
>
>
--
R. Allen Wyke
Chief Technology Officer
awyke@blue292.com
919.806.2440