[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=37602#comment-37602 ] 

Art Botterell commented on EMERGENCY-26:
----------------------------------------

Norm, I appreciate your flexibility, and of course you and your agency are alway entitled to your own judgements.  I just hope you won't dig yourself too firmly into a position until we've had a chance to explore this together.  Trying to boil this down in my mind I'm hearing two concerns... please let me know if I've missed anything.

The first is that this would be a big change.  Agreed, which is why why I suggested that this particular item would be appropriate for a forward-looking version 2.0 but probably not for a back-compatible 1.3 release.  I wouldn't expect Canada or the US or any other large CAP early-adopter to make this leap anytime soon.  At the same time I don't believe any of us wants to impose our own limits on everyone else.  Anyway, progress will come whether we like it or not... the only real question is whether that progress will come from OASIS or somewhere else.

The second concern is still a bit abstract in my mind, but it seems to boil down to a preference for a few relatively complex CAP alerts rather than more, simpler alerts.  That suggests that you perceive the marginal cost (in some sense) of an individual CAP Alert to be relatively high.  If so I suspect that may be a local artifact of your implementation or processes, because in most digital systems the cost of transmitting an individual message is low, approaching zero.  Usually most of the cost is in routing and parsing, costs which rise quickly with increased message complexity.

Also I think I hear echoes of the problem of CAP's ambiguity as to phenomenon description vs message targeting in space and time ("storm centric" vs "location centric" in your context.)  That's caused implementers a lot of trouble in many places, especially when we need to square the circle between hazard footprints and political/administrative boundaries.  I suspect that distinguishing those two types of location information might get at the root of some of the "bifurcation" and "continuity" challenges you've addressed using complex CAP structures.


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