OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

2.  Primary: National Security/Terrorism

        Secondary:

3.  Primary: Technological

        Secondary:

Walid


-----Original Message-----
From: Art Botterell [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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]