emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency-msg] Minutes from 9/30/03 call
- From: "Walid Ramadan" <WRamadan@blue292.com>
- To: "Art Botterell" <acb@incident.com>,<emergency-msg@lists.oasis-open.org>
- Date: Mon, 6 Oct 2003 14:15:03 -0400
Title: RE: [emergency-msg] Minutes from 9/30/03 call
I am no expert on ICS or UML, but her are my comments on version2 of ICS201 Data Dictionary
- resourceId: why are we limiting the format for this one? ICS instructions suggest a resource ID may vary from a license plate or a vendor name plus anything in between.
- I may be mis-reading this, but how can the "resources" element be optional and the "asset" element be required
- The ICS201 is a 4-page document, and therefore, it must be maintained as such with all its elements regardless of whether information is available to go on all 4 pages. For example, in a paper environment, you do not just take out the resource page of the ICS201 just because you do not need or have any resources, but rather you include it blanc. I would like for our object model to reflect that. In other word, the recipient of the ICS201 should be able to recognize that there were no resources needed. Same applies to "location" and "position" in the object model.
- The multiplicity for "organization", "resources", "location" and "summary" in the object model cannot all be "0…n" simultaneously. We need to capture that constraint., otherwise, what is the point of filling the ICS201?
- In the data dictionary, the "objective" is designated as "optional", but in the object model, it is showing "1..n" multiplicity. Are these two inconsistent?
- A time/date data element is missing under "action" under "summary"
- I am not sure I understand the "0…n" multiplicity between ics201 and incident data elements. Is that implying that the same ICS201 is used for multiple incidents? The purpose of ICS201 is to provide a limited number of users with information on the initial incident response until the first operational period begins
- We made some of the elements that we listed in the data dictionary under "ics201" "Elements and Sub-elements" mandatory, such as msgType, and status. I believe that we agreed to reuse particular set of elements from CAP that provide for identification of the incident to which this ICS is related. Are we trying to translate ICS201 into a CAP message?
- Although designated as optional, the "contact" element under "incident” Elements and Sub-elements" is not necessary because that information is already captured by other mandatory data elements such as preparedName, preparedPosition, and preparedAgency.
- I am not sure I understand under what circumstances the incident element under “incident” Elements and Sub-elements can have more than one <organization> block.
- When it comes to the data element "positionReports", the high level positions such as those making up the Unified Command, Officers, and Section Chiefs are pre-defined in ICS201, although not necessarily deployed in every incident. I think the data model should capitalize on the fact that those positions are well-defined. We can also extend that to all ICS positions including task forces groups, etc.
Walid
-----Original Message-----
From: Art Botterell [mailto:acb@incident.com]
Sent: Wednesday, October 01, 2003 6:58 PM
To: emergency-msg@lists.oasis-open.org
Subject: [emergency-msg] Minutes from 9/30/03 call
NOTIFICATION METHODS AND MESSAGES SUBCOMMITTEE
Conference Call - 30 September 2003 - 12:30 PM EDT
Attending: David Hall, Rex Brooks, Gary Ham, Jerry Weltman, Carl
Reed, Rob Torshon, Art Botterell
- Rex recounted highlights of last week's TC meeting for the folks
who were unable to participate.
- Art and others reported on the successful CAP-based demo event in
Washington last week.
- David led a discussion of the status of the ICS-201 format. He has
incorporated various inputs (from Eliot and others) in version 2 of
the Data Dictionary. Rex volunteered to help David in casting the
format as an XML Schema. The group agreed that we would provide our
comments on the data dictionary in time for next week's call. (A
copy of the v2 Dictionary is attached for reference.)
- Cathy Subatch is on sabbatical for the immediate future. We'll all
miss her detailed minutes and general organizational skills.
- Rex mentioned special populations, and Art suggested that we might
want to consider how such groups might help champion CAP and other
interoperability standards that improve accessibility.
- That led to a brief discussion of PR. Art reminded the group that
any press mention of OASIS or its processes should be coordinated
through the OASIS PR mechanism.
- The call adjourned at 1:00 PM EDT. << File: ICS_201_Data_Dictionary_v_2.doc >> << File: ATT199327.txt >>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]