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-26) Eliminate multiple Infos altogether


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

Norm Paulsen commented on EMERGENCY-26:
---------------------------------------

Follow on to the discussion in issue #25

One of the principles that we in Canada follow is the CAP principle of "wipe and replace". In other words, the new CAP message, with all its info blocks, is a wipe and replace activity on the part of the consumer. If the consumer system gets an Update, they wipe all info block messages that are playing based on the old CAP message and then play all the new info block messages that come with the new CAP message. This allows me to decouple info blocks between past and current messages as the wipe action takes care of the old ones (an Alert block level activity) and the play action is only concerned about the new ones (an info block level activity).

This is part of the bifurcation discussion, but essentially, by approaching it this way I can reduce the number of info blocks in later messages as the large moving storm slowly dies out. I also don't have to index an info block in order to treat the information as if it was its own alert saving me a lot of work as I only have to concern myself with what I want said going forward, which is how the forecasters on the desk currently work. I became very fond of CAP because it allowed me to do this.

I would have to say I am not in favor of this motion.

Side note: I would be more likely to use separate CAP files for languages than for the other distinctions but because Canadian federal policy is "both languages are to be serviced equally", at least on my originating end. Using one CAP file for both is the only way I can guarantee this without ever having to explain why some distribution foul up was the cause and not our system.





 

> Eliminate multiple Infos altogether
> -----------------------------------
>
>                 Key: EMERGENCY-26
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-26
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Art Botterell
>
> This is a more radical version of EMERGENCY-25:  Even in the case of multi-lingual messaging the requirement (which is essentially administrative) could be met by issuing multiple CAP messages, each in a different language.  This would simplify both implementation and operation by decoupling the workflows for different languages and generating a separate CAP Alert for each.
> Since relatively few message originators are fluent in all the languages required of them by their various local operating rules, those language-specific workflows are necessarily different; coupling them in the technology can lead to avoidable delays and complications.
> (The original design was informed by preconceptions and political pressures and I take full personal responsibility for its imperfections.)



--
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]