[OASIS Issue Tracker] (EMERGENCY-26) Eliminate multiple Infos altogether

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

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

I agree with your comments and I agree that for some they may be better off doing just that for the reasons you state. But since CAP offers me the choice I take the one that works best for me. You are correct that I am using it for differnet areas. As for different time frames, actually those end up in separate CAP message chains.

The problem of Bifurcation is the problem of dividing up something (in this case information) into parts as a result of differences between those parts. Continuous division of  Alert information into multiple parts, such as what happens over time when a large storm with changing characteristics threatens a changing lcoation over time as the storm moves along and updated wanring messages are issued. Converting a storm centric forecasting approach to a location centric alerting approach creates the bifurcation problem when using separate CAP messages. Its the consequences that we are concerned with more so than the bifurcation itself that is the problem. I would address those in the what I write later, with examples, but you may argue, multiple CAP messages or Multiple Info blocks, what's the difference - Its bifurcation either way? The answer is that with the multiple info blocks approach, it is much easier to apply the wipe and replace principle with much fewer CAP messages overall coming out. The alert (wipe) action and the info (play) action are decoupled which is not always the case in consumer systems that don't understand this distinction. Secondly, the "continuity" from message to message and from area to near by area is not impacted by the originating system or the distribution network (if something is late or missing on one consmer system and not another it is their system). It makes diagnosis/troubleshooting  of problems much easier.

Your solutions are fine. They may be the best for some. But I/we chose the practices we employ here as a group since they appear to serve us best (just opinion). Note: we are both originator and consumer.

If you look at the Google site http://www.google.org/publicalerts/. You can often see how NWS has many more Alerts over a small area than we do. This is not the bifurcation problem per se but it shows how the division of Alerts looks like between our two services (at the time of this posting there are numerous Flood Alerts just south of Indianapolis each from a separate CAP message).

If town X has a flood warning you won't be able to see the Tornado watch for the same town unless you click on a nearby area and read it and realize that town X is included. As it is, our Env Can alerts would result in the same thing in such a case; but I point it out only as an example of a continuity issue. I can't say I've eliminated with our approac across different hazards (like this example is) but I feel we make it easier across different locations within the same hazard for consumers. Its not a great example but its a start.

Note: I would use the standard no matter what it evolves too but this position is where I have evolved to. Its just one person's opinion.





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