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

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

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
>
>
> From: CONSULTRAC [mailto:rcarlton@consultrac.com]
>
> I think that our attempting to define a "holistic" XML-based ICS 201 
> is a
> flawed approach and beyond our scope. Perhaps we should prepare an 
> XML-API
> process spec that acknowledges the specific elements and name types
> referenced in the ratified NIMS-construct, but leave the front end
> formatting to the marketplace. In my view this places us where we 
> belong; at
> the "standardized data exchange protocol" level rather than the
> "applications/forms development" level. The latter posture suggests 
> certain
> product biases that I do not think we want attached to the committee's 
> work.
>
>
--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net