[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Inputs from PPW CAP Workshop
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]