RE: [emergency-msg] Updated CAP (v. 0.8a) DOM and Dictionary

[Art Botterell <acb@incident.com>]

Walid -

Do you have a primary source for that list?  I suspect that somewhere 
there's a source document for this list, with definitions.

Thanks!

- Art

At 4:36 PM -0400 6/26/03, Walid Ramadan wrote:
>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:acb@incident.com>mailto:acb@incident.com]
>Sent: Thursday, June 12, 2003 12:05 AM
>To: emergency-msg@lists.oasis-open.org
>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