[CAP] multiple infos faq entry

[Mick Jagger]

Multiple Info Blocks

	This would certainly be one of the top questions on a CAP FAQ.  The problem arises from the fact that an XML schema cannot express a lot of the logic and implementation decisions.  This is where the CAP documentation is really lacking.  Here is the "rough" answer to how multiple info segments are used, with examples that need to be created for illustration.

Multiple info segments are used to define related parts of the same incident, since they share the same primary incident tracking info (identifier/sender/sent).  The 2 most common uses are expressing an alert in multiple  languages, and providing different response information to different audiences.  In both cases, there are certain elements that all info segments share.  If these elements differ, then the info segments don't belong in the same alert message and should be issued seperately.  

For multi-language alerts, the elements that are free-form should be expressed in the language defined for that info segment, all other elements and values should remain the same.  Elements that should be composed in the info segment's language are, event, audience, senderName, headline, description, instruction, contact, areaDesc, and resourceDesc.  The language value should change for each info segment and all other elements and values should be identical between info segments.

Multi-audience alerts also have elements with differing values and values that should remain identical.  The most common scenario is where a portion of a city is issued a shelter-in-place and the remainder of the city is given a different set of instructions.  In this case the area blocks, urgency, severity, certainty, and instruction values change.  Or perhaps there is a timed series of info segments where at this time a certain area needs to do this, and in 1 hour from now, another area needs to do that.  Perhaps rolling power blackouts, etc.  The area blocks are the primary factor in these types of alerts.
For these multi-audience alerts most of the elements can change between info segments with only a few "thread" elements needing to remain identical in order to "stitch" the info segments together.  These are category, event, and eventCode.  Event Codes become vitally important in this case.  Multi-language alerts can also be used along with multi-audience.

Now both of the above scenarios can also be achieved by issuing single info alerts.  There is nothing stopping people from sending all of their alerts in this fashion if they feel that multi-infos are too hard to implement and their alerts will work just fine with other multi-info implementations.  In fact sites that choose to go single info, could issue their alerts as single infos and when they get an incoming alert that has multiple infos, they could just break it up into seperate messages for processing prepending the same alert block to each info segment.

However implentations that use multi-infos gain some important advantages.  Chief amoung these is better message management and coordination.  Right now the CAP incidents element is used to collate multiple messages.  However this element is poorly defined and difficult to use.  Kind of like the references element was in CAP 1.0  So it can get very confusing if you are issuing 3 different alerts for 3 languages and end up with an initial Alert, 4 Updates and a Cancel.  Thats 18 seperate messages to keep track of and goes against the grain of some basic software engineering principles of reuse.  

It also causes alert filtering problems.  Say I speak language X.  When an alert is issued with language X,Y,Z in multiple info blocks, I can filter out the other blocks and only receve the message in my chosen language.  However for single info blocks, I can't filter anymore and will receive the message in all 3 languages.  This is because a properly built filtering system will try to send me my chosen values, but in the end should send me a default.  So in the single info case, my chosen language isn't available, but there could be important information in the alert and the receiving system doesn't know that further messages contain the exact same info in my chosen language, so its proper fall-back behaviour is to send me the alert regardless.

... more to follow

-- 
lists at jpw.biz
--