[OASIS Issue Tracker] (EMERGENCY-34) Support the concept of an event in CAP

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

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

Eliot Christian commented on EMERGENCY-34:
------------------------------------------

I see the proposal labeled "option 4" as an alternative syntax intended to accomplish roughly the same change as what was proposed as option 3. That is, in both option 3 and option 4 the CAP schema would define two kinds of alert/info elements: one qualified as referring to the alert and the other qualified as referring to the event. 

From a semantics perspective, I take issue with the assertion that option 4 is more simple and backward compatible than other options. Although it does use a simple syntax mechanism (a new element or attribute), its effect would be a complex change in the CAP element definitions. In option 4, each of the CAP alert/info sub-elements would exist in two versions, one qualified as "of the alert" and the other qualified as "of the event". 

Specifically, option 4 would replace the definitions of the 21 existing alert/info sub-elements in favor of these sub-elements: language of the alert, category of the alert, event of the alert, responseType of the alert, urgency of the alert, severity of the alert, certainty of the alert, audience of the alert, eventCode of the alert, effective of the alert, onset of the alert, expires of the alert, senderName of the alert, headline of the alert, description of the alert, instruction of the alert, web of the alert, contact of the alert, parameter of the alert, resource of the alert, and area of the alert. Option 4 would also add 21 new alert/info sub-elements: language of the event, category of the event, event of the event, responseType of the event, urgency of the event, severity of the event, certainty of the event, audience of the event, eventCode of the event, effective of the event, onset of the event, expires of the event, senderName of the event, headline of the event, description of the event, instruction of the event, web of the event, contact of the event, parameter of the event, resource of the event, and area of the event.

Looking at the resulting option 4 alert/info sub-elements, some of them  make no sense, e.g., event of the alert, eventCode of the alert, senderName of the event, instruction of the event. For this reason,  I recommend that we set aside option 4 as untenable as proposed.

I further suggest that any refinement of the basic idea behind option 4 should be further discussed only in the context of option 3. I suggest this because it would be dangerous to use the simplistic syntax mechanism of option 4 to effect the intended profound change in element semantics. In practice, nothing is more essential to the purpose of CAP than assuring that those who create an alert are very clear about the meaning of each CAP element. Having an element name like "eventArea" (options 1, 2, and 3) is much clearer than having two elements each named "area" and distinguished only by the value of a separate element or attribute (option 4).


> Support the concept of an event in CAP
> --------------------------------------
>
>                 Key: EMERGENCY-34
>                 URL: https://issues.oasis-open.org/browse/EMERGENCY-34
>             Project: OASIS Emergency Management TC
>          Issue Type: Bug
>          Components: CAP 
>            Reporter: Steve Hakusa
>
> CAP already has a number of fields describing the event for which an alert is being issued.  Two separate issues in this list wish to add more, and more structured, information about the event
> https://issues.oasis-open.org/browse/EMERGENCY-17 : Add event expiration element
> https://issues.oasis-open.org/browse/EMERGENCY-16 : Support CAP event location and movement
> These issues and other points of discussion may point to the need for CAP to have a more structured representation of an event and its metadata.
> This issue is meant to contain proposals for how an event could be more formally represented in CAP.



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