[CAP] CAP 2.0 proposal

Mick Jagger lists at jpw.biz
Tue Mar 11 09:19:37 PDT 2008


Hi,
	I believe the solution to Jim's problem of determining when a substantive change has been made versus a minor correction for spelling errors is solved by 2 features of the current CAP 1.1 spec.

The first is proper use of the msgType and references elements.  This way a feed consumer can compare the difference between the previous message and the new message and see that only 1 character changes in the description.  Key to this feature working is that the feed publisher must keep original messages intact so that comparison can take place.  Overwriting the previous message with the new message, then referencing the previous message which can no longer be accessed, is causing the problem.

The second is the use of a CAP profile/extension.  This is something the OASIS group needs to outline but it doesn't require any changes to the spec, just clarification.  However valueListURN would be a very useful addition to a future version of CAP.  An extension defines some optional elements such as parameters, eventcodes and geocodes and their values.  So the NWS would define and publish their own extension.  In the extension could be a parameter value list for the changes that are made to a message's content, so valueName = contentChange and value could be a list that includes things like spelling, missing data, language translation error (Canadian extension includes this already), oops my bad, etc.  When a minor change is made that is non-substantive, the creator could check a box that corresponds to the reason and the extension parameter is added to the message allowing readers to parse it accordingly.

-- 
lists at jpw.biz
--


More information about the CAP-list mailing list