CAP Comments

[Jacob Westfall <jake@jpw.biz>]

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.

- 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.

- 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.

- 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.

- 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.

-- 
jake@jpw.biz
--