Inputs from PPW CAP Workshop

[Art Botterell <acb@incident.com>]

Friends -

Last week's CAP workshop at the Partnership for Public Warning's 
annual convention in McLean, VA turned into an incredibly active and 
productive two hours.  We had 26 participants, with a good mix of 
emergency managers, technology providers, academics and other allies 
and including several members of this list, who will doubtless have 
some of their own take-aways to offer.

A PDF version of the slide deck (926kb, alas!) is posted at 
<http://www.incident.com/cap/docs/ppw_wrkshp_5-12-03.pdf>.

After a quick review of our process and progress so far the 
discussion focused on a few of the core terminology issues.  A few 
key inputs from the discussion and some suggestions for implementing 
them follow:

* <msg_type/> - There was some divergence within the group as to the 
usefulness of the "ack" and "error" message types.  Some folks saw 
value in them, some thought they were unnecessary, and some thought 
we need a more complete message-management facility within the alert 
message.

* <msg_status/> - The chief suggestion was that we add a "system" 
message category for system advisory messages (e.g., protocol 
updates).

* <msg_scope/> - We got busy here.  The discussion of the 
"restricted" value led to the suggestion of providing an optional 
element to describe the restriction rule in free text.  Likewise, the 
discussion of the "private" value led to a parallel suggestion that 
we add an element where an explicit list of addresses (probably 
restricted with a namespace) could be included.

* There was also a request from one system provider for a <secure/> 
boolean to support a particular feature of their product.  It 
occurred to me that maybe it would make sense to provide a general 
<msg_code/> element that would allow system-specific codes in the 
<alert/> block, paralleling the flexibility offered by the 
<parameter/> element in the <info/> block and the <area_code/> 
element in the <area/> block.

* The <severity/> and <certainty/> elements passed muster, but the 
<urgency/> element got a thorough working over.  After much 
discussion we came away with a recommendation that the definition 
clarify that this refers to the time available until 
protective/response activity should begin, NOT till the time of 
onset.  In addition, a simplified set of tokens... "Now", "Soon", 
"Later", "Past", and "Unknown"... won some acclaim.

*  We ran out of time before giving the <event_cat/> values the 
treatment, but I'm told there's a standard list of 23 or so 
categories in use elsewhere, so maybe that's what we should use.  In 
any event, it was suggested that multiple categories should be 
enabled.

Overall, there seemed to be consensus for our general approach and 
the current overall message structure.  We'll get to present this 
again next month at the World Conference on Disaster Management in 
Toronto, another opportunity to get some user insights on our draft.

As ever, your comments and suggestions are solicited.

- Art