[CAP] handling optional fields

[Art Botterell]

On Jun 3, 2006, at 6/3/06 6:21 AM, Mick Jagger wrote:
> 	If HazCollect needs to truncate a CAP message's contents in order  
> to retransmit over a new medium, then it should be well within  
> their rights to decide the truncation policy.

And indeed they are.  Truncation isn't the issue here.

> 	However I question their policy in this case.  If a message comes  
> in with an instruction and a description.  The description should  
> be dropped in favour of an available headline instead, which  
> already has a suggested shorter size.

That's an interesting idea.  Just goes to show that there are a  
variety of ways the legacy system requirements could be addressed,  
and that it can be productive to ask the community for suggestions.

> 	Also, because of the limits imposed on HazCollect and its need to  
> retransmit, maybe they should be releasing a schema for a custom  
> field to all submitters.  If you're going to transmit via  
> HazCollect, then fit your message in such/such custom field,  
> formatting to their guidelines, and they'll use this field instead.

Hmmm... if implementers start adding new fields with semantics that  
overlap the existing ones, what happens to interoperability?  How do  
receivers know what to expect?

> 	All the larger users of CAP, national governments especially, seem  
> to be keen on taking the standard and adding their own custom  
> fields, formats, etc to suit their own local needs.

Really?  Maybe you could provide some examples.  A lot of  
implementers use the provided <parameter> and <resource> capabilities  
to provide more detailed information, but this is the first case I  
know of where someone has unilaterally redefined the meaning of an  
existing CAP field.

> 	Maybe something for the next release of CAP is a priority list of  
> field elements.  If a message has such and such, then this field  
> takes priority, then this field, and so on.  This won't be the last  
> time the truncation and selective field choice discussion will come  
> up, so build in some rules for implementers to follow.

My hope is that we will, in fact, put a stake in the ground and say  
"The spec is the spec, and what diverges from the spec isn't CAP."   
The optionalities in CAP were provided to avoid forcing senders to  
fill their messages with empty fields where particular items of  
information aren't available (e.g., an individual sensor report might  
have a description but offer no instruction... not a good practice  
for public warnings, but maybe appropriate in a narrower  
application.)  Those optionalities were never intended as an  
invitation for each implementer to redefine the meanings of fields.

- Art