RE: [emergency-comment] CAP Comments

["David RR Webber \(XML\)" <david@drrw.info>]

Jake,
 
Just a quick FYI - registering a mime-type - this is a non-trivial exercise!  First you have to have major support for the new type - and show thousands of users - then you have to get it thru the committee process.  Figure at least one year+ for that.
 
I suspect that suitable mime-type combos already exist for what you want - xml/text et al may suffice.
 
See my further thoughts below.
 
Thanks, DW



-------- Original Message --------
Subject: [emergency-comment] CAP Comments
From: Jacob Westfall <jake@jpw.biz>
Date: Mon, May 26, 2008 12:35 pm
To: emergency-comment@lists.oasis-open.org

Hi,
Responding to the call for CAP comments, here are some minor changes that could comprise a version 1.2

- register a mime-type - a mime-type for CAP alerts should be registered and noted in the spec, a suggested type is application/common-alerting-protocol+xml

- Data Dictionary note - required CAP elements should not be allowed to have Null values in the dictionary or the schema. Having a Null identifier/sender/event/resourceDesc/areaDesc element should not be allowed.
 
[drrw] Overall I agree this is good practice.  If null is needed - support it thru an optional attribute codelist - such as:  content="INC"  - where codes are "INC - incomplete" "UNK - unknown" - "NA - not available" and so on - to clarify why the data is not provided at this time.[drrw]

- references element - all messages in an incident grouping should be referenced each time a new message is sent out. This ensures that proper incident chains can be built even if some messages are not received. Also a caution should be added regarding referencing out of group messages causing "cross-pollination" issues which can corrupt the incident chain to clarify the use of references versus incidents.
 
[drrw]  various ways of doing this - XLink may be suitable - or a simpler approach with href and attribute carrying state / linkage action codes. [drrw]

- incidents element - this element should be more clearly defined to ensure interoperablity between systems. A recommended format is IDENTIFIER,URI with multiple values separated by whitespace. To be inline with Oasis standards XRI could be substituted but there are still problems with W3C right now. The transport method must be included in the URI to allow a receiving system to be able to download this incident message if need be and should point to the actual CAP message itself. For two-way systems even those like DM-Open using SOAP can use the URI, while one-way systems can use the identifier to correlate their received alerts.
 
[drrw]  suggest using attribute for transport method codes instead of overloading the URI itself. [drrw]

- event element - add a size restriction here, perhaps 50 characters. Systems need to standardize on some display values and event seems to be a good choice since its required and if it was kept short, looks good on a situational awareness screen showing a large listing of alerts.
 
[drrw] recommend avoiding size restrictions - always ends badly! Suggest lists instead - so people can just display the first entry in list - and rest are optional details.  Also list entries can have extensible types - so make rich and simple information pattern [drrw]

- responseType element - add an option of Avoid - This was mentioned before by others. Based on past experience a large majority of alerts could use this new responseType as it more accurately describes the recommended action than Execute.

- instruction element - add a size restriction here, perhaps 250 characters. Text-to-speech for broadcast and TV crawls will use this value to provide instructions to the public and if the value is too long, say a couple paragraphs, then its value is greatly diminshed. Originators need to sum up their instructions to keep them useful for the public.

[drrw] Look at adding Atom compatiblity instead - no need to re-invent wheel - and media sources already work with Atom feeds. Atom also is extensible - see my notes on event element - same thing applies [drrw]

-- 
jake@jpw.biz
--

-- 
This publicly archived list offers a means to provide input to the
OASIS Emergency Management TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: emergency-comment-subscribe@lists.oasis-open.org
Unsubscribe: emergency-comment-unsubscribe@lists.oasis-open.org
List help: emergency-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/emergency-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency