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