OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (EMERGENCY-25) Restrict use of multiple Infos to multi-lingual versioning


    [ https://tools.oasis-open.org/issues/browse/EMERGENCY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37590#comment-37590 ] 

Norm Paulsen commented on EMERGENCY-25:
---------------------------------------

Art: In the spirit of open discussion I offer the following....

Before commenting on this Issue, I would first point out that in Canada, the use of Multiple Info Blocks is quite common. In Environment Canada, we have a minimum of 2 info blocks per CAP message (based on language differences) but we also often have 4 info blocks and sometimes 6 info blocks. In our usage right now, we distinguish by different areas and half of our info blocks are in English and half are in French. We were planning on using more distinctions, and hence more info blocks, in the future as well.

I always thought the CAP standard originators were absolutely correct in allowing that to be the standard. As an originator of Alerts it makes my life actually easier than more difficult to use them. From experience, I believe that consumers often struggle with them, but once they understand them it helps them understand alerts a lot better (I acknowledge that some do not get to this point and some have invested time, money and effort and do not want to change to handle multiple info blocks). U.S. vendor equipment brought to Canada often struggle with our EC alerts for this very reason.

We also investigated issuing numerous CAP messages, one per info block, but this created other problems. The two main problems for this were the continuity between a series of messages and the bifurcation problem. Both of these surface when we are dealing with large moving events - a time when you especially want the system to be helpful and not a hinderance. These two items would take a long discussion each to get into (see below) but presently we don't experience those problems.They are primarily originator issues. 

Adding to that is some of the policy we have to deal with in Canada. Federal agencies that distribute Public Alerts, have to do so in both offical languages simultaneously. In other words, if we have any free form text in one language, we have to hold it back until its translated and then we can send both text out at the same time. I disagree and am frustrated with that policy. Nevertheless, what we do in Env. Can. is send out an intial CAP message with pre-defined generic text in both languages and then when the translation comes back we Update the previous CAP message with identical information but this time the text is all there in both languages.  We put a <parameter> marker in the CAP message letting those that don't care about any dicsussion text that this is bascally a repeat and if their model allows them to they can ignore this Minor Update. Bascially we feel we are forced to do this because of Federal Policy we have no control over.

So with these three problems alone (two I would be happty to elaborate on a call), I feel that the multiple Info block is my saving grace that makes my originator situation a much easier world to work in. 

I would have no problem if a community like say IPAWS, or other, made a rule on "no multiple info blocks". If I wanted to play in that community I could easily break my original CAP message into separate files to service it but that would come at a cost to me and an understanding that other community may experiece continuity, bifurcation, and language policy issues knowning that it was their policy that introdcued those things, not me the originator.

I would have to say that I am not in favour of such a rule.


> Restrict use of multiple Infos to multi-lingual versioning
> ----------------------------------------------------------
>
>                 Key: EMERGENCY-25
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-25
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Art Botterell
>
> Currently CAP permits the use of multiple Info blocks for a variety of reasons: to address different areas, different timeframes, even different hazards altogether within a single CAP message.  
> Although well-intentioned, experience has shown that this is unnecessarily complex.  In practice the use of multiple Info blocks is quite rare except where the same message needs to be presented in multiple languages.  The other cases can be addressed more simply by sending multiple CAP Alerts.  
> This would significantly simplify implementations at both the originating and consuming ends and also decouple potentially conflicting routing requirements. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]