MHonArc v2.5.0b2 -->
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]