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-20) Change incidents format

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

Art Botterell commented on EMERGENCY-20:

<incident> is not a reference to a message, but rather a shared name, as per ICS, for the inherently fuzzy collection of events and activities emergency managers call an "incident."  The goal was to allow multiple messages referring to different aspects or phases of an incident to be associated.

This is highly problematic in practice for a number of reasons.  Incidents aren't atomic... they sometimes merge and sometimes split.  Also, incident names frequently aren't assigned until well after alerts would be issued.  And of course its frequently the case that a single alert may refer equally to a vast number of individual incidents, e.g. in the case of a hurricane warning.

Thus this cross-referencing may sometimes be feasible later, it's only rarely possible at the time alerts are authored.  If anything I'd suggest considering whether <incident> should go on the "it was a good idea, but" stack and removed from future versions of the spec.

> Change incidents format
> -----------------------
>                 Key: EMERGENCY-20
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-20
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Tony Mancuso
>              Labels: CAP
> Jacob Westfall;  alert.incidents: this element should be more clearly defined to ensure interoperability between systems.  A recommended format is IDENTIFIER,URI with multiple values separated by whitespace.  To be in line with Oasis standards XRI could be substituted but there are still problems with W3C right now.  The transport method must be included in the URI to allow a receiving system to be able to download this incident message if need be and should point to the actual CAP message itself.  For two-way systems even those like DM-Open using SOAP can use the URI, while one-way systems can use the identifier to correlate their received alerts. 

This message was sent by Atlassian JIRA

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