Updated CAP (v. 0.8a) DOM and Dictionary

[Art Botterell <acb@incident.com>]

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

%CAP_0.8a_DOM_and_Dict.pdf

CAP_0.8a_DOM_and_Dict.pdf