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

["CONSULTRAC" <rcarlton@consultrac.com>]

And to add my clarifying "two cents;" while ICS forms do currently differ
from place to place, the elements associated therein are fairly
"doctrinally-standardized," i.e. essential organizational structures and
field-name taxonomies are, in the main, common across all forms types
regardless of a name element's particular placement within a localized form.

Additionally, it is my intuition is that any current regional mis-matches
are going to be addressed and standardized as NIMS evolves, and probably
pretty quickly; with emphasis on FEMA's version of the doctrine since they
are a Federal agency and NIMS embodies a  Federal program perspective.

My point is it seems more prudent to develop a standardized back-end
data-exchange specification that recognizes the organizational and elemental
structures of common ICS elements, while remaining transparent to the
subjective nature of a particular developer's front-end format. This should
allow us to provide near-term as well as scalable support as a standardized
data exchange mechanism but leave room for  NIMS to "guide" us further as it
evolves. That way we won't be painting ourselves into a corner, or appearing
to produce yet another product variant that may, or may not, be NIMS
compliant in the final analysis.

Rick



---- Original Message ----- 
From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
To: "'R. Allen Wyke'" <emergency-tc@earthlink.net>
Cc: <emergency@lists.oasis-open.org>
Sent: Thursday, April 01, 2004 11:40 AM
Subject: RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded


> 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
>
> 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.
>
>
>