RE: [emergency] CAP-AP Question 1 - Clarification of CAP <info> block issue

["Paulsen,Norm [Ontario]" <Norm.Paulsen@ec.gc.ca>]

Hi Greg

Here is my response based on my input into the CAP-Canadian Profile. Other parties involved with the CAP-CP may wish to add.


a) multiple <eventCode> elements within a single <info> block

This one has to do with interoperability between systems. As an issuing implementer, I would like my CAP message to be understood by multiple systems, not just my own. I would like to be able to create one CAP message and send it to all systems without having to run an operation where I have to create several CAP messages depending on who the client is. For example, I would identify in the <valueName> for one <eventCode> that I am using the Canadian Event reference list and the code XYZ whereas I would identify in the <valueName> for another <eventCode> that I am using the US SAME code and the code ABC. It would be incumbent upon the recipients of my CAP message to look for the <eventCode> that applies to them based on the valueName. In some cases it may be both, as a vendor that sells equipment to both Canadian and US interests may have an interest in both.

The above is the main reason but the usefulness doesn't stop there.
- If there were a global event list, I would have one eventCode for Canada and one for the global list.
- If there ever are two Canadian lists, I would use both
- If versioning is addressed within valueName with a URN type of solution then you can version up and maintain existing versions simultaneously without having to synchronize everyone moving up at the same time. This would involve using two or more eventCode elements. Versioning is an question that has come up at times.
- If, as in the case of MeteoAlarm, they want to use it as a display code then they can (not my preference though) but I suggest that they also use an event code that is interoperable with others (similar to the second bullet above).


b) multiple <info> blocks that only allow one <eventCode> per block.

We don't do have this restriction for the same reason as given in a). Maybe based on the above your question will change.

NOTE: The Canadian Profile concerns itself with different events addressed in different info blocks within the same CAP message file that are both subject to the references element and the "supersedes" condition during updates. Basically, if an update to one event occurs, and the references element notes the previous alert message then the second event is being updated whether it really is or not. Either, its not, and we are misrepresenting that it is (by including it with new updated times), or it was addressed and updated properly but then the issuer may have jeopardized some time spent in making sure the second event was up to date when the first event initiated the update in the first place with some time critical information.

Your questions will make me re-think the wording in our rule set as it may not be interpreted correctly.


Norm Paulsen
Service Strategies and Standards Section | Section des stratégies et des normes de service. 
National Services Operation Division | Division des services opérationnels nationaux 
Weather & Environmental Prediction and Services Directorate | Direction des prévisions & services météorologiques et environnementaux 
Meteorological Service of Canada | Service météorologique du Canada 
Environment Canada | Environnement Canada 
4905 Dufferin St. Toronto, Ontario M3H5T4
Tel:  416 739-4190
Fax:  416 739-4967
Email: norm.paulsen@ec.gc.ca


-----Original Message-----
From: gregory.trott@ag.gov.au [mailto:gregory.trott@ag.gov.au] 
Sent: April 20, 2011 7:45 PM
To: emergency@lists.oasis-open.org
Subject: [emergency] CAP-AP Question 1 - Clarification of CAP <info> block issue

As highlighted in the EM-TC Meeting Notes from March 29, 2011 (Item 4), this question is one of two questions originally identified in the Australian "Request For Assistance - CAP-AP Development" document that I posted on the EM-TC website on 2011-03-18. 

I wish to seek EM-TC member responses to the following question, in order to obtain feedback from individual members that may possess experience with CAP issues that they are willing to share with the Australian CAP-AP project.


Question 1:  What are the advantages and disadvantages with allowing a CAP message to include:

a) multiple <eventCode> elements within a single <info> block; and

b) multiple <info> blocks that only allow one <eventCode> per block.

Preferred deadline to receive responses to this question is no later than 6th May 2011.


Background information:
------------------------
1) This information is being requested in order to resolve the follwoing issue being expressed by an Australian CAP Stakeholder: 

With multiple <info> blocks the single CAP message could contain <info> blocks assigned to areas under varying levels of threat.  The alternative approaches are: 
 the overkill of sending an alert message across a broader geographic area just to ensure it covers the threat area, or  sending multiple CAP messages for one event.  


Current partial explanation already appearing in the CAP-AP document:
-----------------------------------------
1) The CAP-AP document posted by me on the EM-TC website (titled CAP-AP Discussion Paper (1 of 3)) already addresses part of the answer to this issue in the following sections:
 
(Para 1.) A single CAP <alert> will be created at message origination with multiple <info> blocks  one <info> block for each disparate exchange partner, as necessary.

(Para 1.2)  the resulting CAP v1.2 structure as a single CAP v1.2 <alert> block that contains multiple <info> blocks  one per exchange partner. The intent of CAP-AP is to tailor one <info> block specifically for each particular exchange partner as necessary within criteria required for a profile.

2) I have also seen the following explanation included in the CAP-CP:  

The OASIS CAP standard allows for the use of multiple <info> segments per <alert>, but only provides for a single message identifier per <alert>. Further, OASIS CAP allows for updates and cancellations of <alerts>. The challenge is what is to be concluded when faced with an update or cancellation of only one of a multiple of <info> segments, if each <info> segment were to refer to a different event.  To avoid any potential confusion, the Canadian Profile limits each CAP <alert> to a single <info> segment except for the purpose of replicating alerts in additional languages. The only difference between multiple <info> segments is to be the value in <language>, and the language used in the descriptive fields. They will pertain to the same event type.



Thank you in advance for any comments you are willing to contribute in repsonse to this question.

Regards,

Greg Trott
CAP-AP Project Manager