Title: RE: [emergency-msg] Updated CAP (v. 0.8a) DOM and Dictionary
Looking at the list of values for "Event Category", I think it can be expanded a little. It is my understanding that FEMA's Emergency Management Exercise Reporting System (EMERS) has a pretty exhaustive list of event categories in that system that I think can be beneficial to use in CAP. This is particularly beneficial when CAP is used for notifying emergency responders, where more specific event types are warranted.
Here's a list of EMERS' event categories. It categorizes events into primary and secondary. You can select a primary event and pick one or more secondary ones:
1. Primary: Natural
Secondary: Avalanche
Drought
Earthquake
Flood
Hurricane
Landslide
Other (describe)
Subsidence
Tornado
Tsunami
Volcano
Wildfire
Winter Storm
2. Primary: National Security/Terrorism
Secondary:
Biological
Chemical
Civil Disorder
Cyber
Explosive
Hostage
Nuclear/Radiological
Other (Describe)
3. Primary: Technological
Secondary:
Dam failure
Hazardous material – Fixed Facility
Hazardous material – Transportation
Other (describe)
Power failure
Radiological – Fixed
Radiological – Transportation
Structural Fire
Transportation Accident (Air, Rail, Highway, Water)
Walid
-----Original Message-----
From: Art Botterell [mailto:]
Sent: Thursday, June 12, 2003 12:05 AM
To:
Subject: [emergency-msg] Updated CAP (v. 0.8a) DOM and Dictionary
Friends -
Per our conversation on Tuesday and various personal communications,
the attached combines the updated CAP alert message document object
model with the newly 11179-ized data dictionary, all for your review.
It may not show on a printout, but on the screen you'll see that I've
highlighted various updates in yellow. Aside from a number of name
changes for simplicity's sake, here are a few changes you might find
worth reviewing and discussing:
In the <alert> structure:
* The message distribution scope element (<scope>) has been
redesignated as optional with a default of "Public". [Didn't seem
this one would be used often enough to justify making it mandatory.]
* For cases where explicit addressing is required, the format for
listing multiple addresses (in <address>) is specified.
* The handling code (<code>) element now may have multiple
occurrences, and a note is added to delineate its uses.
In the <info> structure:
* The event category (<category>) may now have multiple instances.
[Note that we're still reviewing our list of categories; Jerry
Weltman has that ball right now.]
* I've proposed different labels for the <urgency> categories. [I'm
trying to cast all the U/S/C codes as appropriate adjectives, in part
so they could be strung together in a sentence and make sense.] The
definitions of the categories are unchanged.
* Likewise I've proposed different labels for the <certainty>
categories. Again, the definitions are unchanged.
* The audience-targeting code (<code>) is annotated [to distinguish
its use from those of the <scope>, <restriction> and <address>
elements.]
* The usage of the <web> element (formerly <info_url>) has been
expanded [to allow it to point to any textual resource available via
a URI.]
And in the <area> structure:
* After a very interesting discussion with a chap at NWS headquarters
who's been experimenting with a CAP application, I've proposed
simplifying the rules for this block. [Basically, I'm proposing that
any combination of polygons, radii and geocodes be permitted, with
the <area> describing the union of all the included elements. The
same thing could be accomplished with multiple <area> blocks anyway,
so why make things complicated?]
* At the same time, I've gently deprecated the use of system- or
agency-unique geographic codings (<geocode>) alone without equivalent
polygon and radius representations. [Using agency-unique codes means
the receiver needs to know that coding scheme (and how many others?),
which seems to cut against our goal of interoperability.]
I've also appended a couple of implementation notes regarding
geospatial representations (thanks to Eliot and the GIS team) and
security (thanks to Rick and the Infrastructure team.) And some
OASIS legal boilerplate just to make it look like we're
serious-minded folks.
Obviously all these changes are just proposals and subject to
discussion... but I'd encourage you to treat this as a
very-nearly-final draft... 'cause we'll need to report something up
to the committee level by month's end to keep our TC on schedule.
Thanks again for all your hard work and wise inputs. A number of
folks are starting to pay attention to what we're doing. We should
be proud.
- Art
