[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Groups - ICS-201-draft0.2.xsd uploaded
Yup, I was hoping that was what you meant. Ciao, Rex At 3:03 PM -0500 4/1/04, R. Allen Wyke wrote: >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 > > >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. -- Rex Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth W3Address: http://www.starbourne.com Email: rexb@starbourne.com Tel: 510-849-2309 Fax: By Request
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]