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