[CAP] Toward CAP 2.0

[Mick Jagger]

> Which is why I'd like to suggest that we on this list... the folks  
> who got the ball rolling in the first place... should take a first  
> stab at some recommendations for the next revision of the OASIS/ITU  
> CAP specification.

I don't think a version 2.0 is what we should be working on.  Version 2 would imply major feature changes/updates and at this stage it would be more practical to look at tweaks and fixes right now.  So perhaps version 1.2 would be better?

The reason I say at this stage, is because there really aren't enough implementations out there.  A lot of CAP setups are using 1.0 and very few sites actually use any of the more advanced features of CAP beyond the required elements.  If anyone is really pushing the standard to the max and running into roadblocks and problems, I'd be interested to hear about it and it would certainly help this discussion.

> 	* responseType: New values needed?

I like the idea about adding "Avoid" to the responseTypes, it would be very useful.  Maybe replace "Prepare" as that type is one that never gets used.  Anything to do with preparation is usually an "Execute" with Instruction.

> 	* area: How to describe motion?

Motion isn't a suitable value for the area blocks.  It would however be very useful in resources as a storm-track image perhaps.  The area block is really the area needing to be alerted.  If you know that 1 hour from now another area will need alerting, either issue a new alert at that time for the appropriate area, or include a 2nd info block with the new area and an Effective/Onset time.  Motion processing logic isn't something that end-user CAP clients should have to build into their systems.

> 	* info: Need for unique identifiers?

I think unique identifiers adds unnecessary complexity.  The vast majority of alerts are issued with 1 info segment, maybe 2-3 if additional languages are used.  If 1 info segment changes and another doesn't, all segments should still be included in the new alert.  If the receiving system has a previous alert from the message chain on file, then it can compare them to find the differences, or if the system is just joining the message chain, it will all be new information.

> 	* Mandatory and optional elements

I don't think responseType should be mandatory since there a lot of cases where it will be None and therefore providing no useful information.  However it would be useful to more strongly link some values together somehow.  For example responseType and instruction, msgTypes Update/Cancel and references, scope and restriction/addresses, etc.  Because even though the spec mentions these links, there are still messages being created without them.  Maybe some big BOLD letters or something.

** Other changes  **

Copying senderName from the info blocks to the alert block would be useful.  Something human readable
and make it mandatory.  Individual info blocks could still have their own senderName as well.  So for example in the alert block would be "Alert Agency", which would be the end user displayed name, and if there was an info block senderName "Bob Smith", it could be appended for end user display "Alert Agency - Bob Smith".

The alert element incidents could be better defined.

-- 
lists at jpw.biz
--