[OASIS Issue Tracker] Commented: (EMERGENCYADOPT-1) Finalize Example Practices: CAP Elements Post-30 day Review Issues

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

    [ http://tools.oasis-open.org/issues/browse/EMERGENCYADOPT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33855#action_33855 ] 

Tony Mancuso commented on EMERGENCYADOPT-1:
-------------------------------------------

Email Comments from Jacob Westfall (JW) and email responses by Tony Mancuso

  JW: Why is there a reference made to CAP 1.0 and 1.1 in the opening of the document?

  TM: Done (deleted these references).

  JW: Circles with radius 0.  This document continues to sit on the fence and needs to be clear on whether this Practice is supported or not.  They are allowed by CAP and have been a common method for denoting a "point" that has been used in practice for a number of years.  Usually at the beginning phase of an emergency when the actual affected area may not be yet be determined but the location is at least known.  If they are to be discouraged, then that argument should be persuasive and well developed.

   TM: The two paragraphs in the current doc regarding 0-radius circles say that use of a 0 radius circle is fine if a point is intended.

   JW: Need further definition and an example of the practice in section F "means to extend a CAP message". There are possible misinterpretations of what this is suggesting is possible.

    TM: Current Section 2.5 gives examples (such as images or audio files) of the type of resource data that can be used to extend a cap message. 

    JW: Usage documentation.  Parameter is not an acceptable location to provide links to documentation.  Why is this even necessary in an actual message?  Is there an expectation that every time someone opens this CAP message it will retrieve the usage documentation and display it as supplemental information alongside the CAP?

    TM: Changed the " should be provided in a <parameter>" to "can be provided ..." to make it clearer that this is an option that may make sense in some applications.

   JW: Expires section.  Expires applies to the information and not the alert message.  This should be made clear as its a common misunderstanding.  The recommendations on how to generate a default expires time are all assuming that its "alert based" and not "information based" which is incorrect.

  TM:  What is the difference between saying the information in the alert expires and saying the alert expires (since the alert contains the information)? It is not conflating the event with the alert, which I believe is the main source of confusion to be avoided. This section is making the important point that an expires time (for the alert/alert information) is helpful so that alert distributors will know how long to keep the alert active.

  JW: "Alert Expiration vs Alert Update".  This statement is contrary to both the specification and all best practices related to composing a message.  I completely disagree with the Practice being advanced here.

 TM: Again, this is saying that the expires time is the time the alert information expires. This section makes the point that it can be used to set the time for the next update (to replace the information in the expired alert with new information in the update). And it makes the related point that a parameter can be used to express the expires time of the actual event (if known)

  JW: Get rid of the Element Examples section.  There should be an example provided for each Practice in the sections above.

  TM: Done.

**********
Email Comments from Norm Paulsen (NP) and email responses by Tony Mancuso (TM):

NP:  Just a comment on the Expires item...
 
CAP doesn't define Alert which is why confusion over <expires> exists. There are at least two different definitions of Alert out there and depending on how one defines it, the practices that are then employed differ and then the confusion arises.
 
On the other hand, CAP defines Message. But the confusion here is that Distributers tend to come in with a different definition of message than CAP. Confusion begins when they start realizing their definition doesn't seem to match in some cases and they wonder what to do next.
 
Basically, a CAP message (as defined by CAP), is a grouping of "one or more" blocks of  information. It's this "or more" part that surprises some. Each block of information has an expires -that is what gets expired. If one were to consider each block of information to be a separate audience message, then we are a lot closer to the truth, and we can expire and audience message from playing on a dissemination conduit.
 
With the two common definitions of Alert, the expiry can be extended to mean the Alert but it's not guaranteed. That only happens with a narrow definition of Alert that some don't share, including Environment Canada.

TM: I'm a little confused by your response. I understand that "expires" is a sub-element of an <info> block, and therefore, originators of messages with more than one info block may intend set it differently for each block (in a message with only one info block, I think distributors should reasonably expect that it applies to all the information in the message), but an "alert" is the name of the containing element of the entire message (i.e., the <alert> element. I think that's why people conflate "alert" with the entire "message." Do some originators mean something other than the entire message when they refer to the "alert"?


NP: Yup, some do. 

Q: Is a CAP msgType of Update implying the Alert is being updated? I.e. Different CAP message - but same alert by def'n.

Distributers often equate alert to a message while issues often equate alert to warning which can be updated.

Anyways, these differences are a big source of the confusion between parties as its not defined going into the discussion. So Jake says expires isn't correct as an absolute - but in single info block msgs that replace previous msgs - it just happens that it does.

Promoting expires to an Alert expiry can lead a distributer to think it always is that way.

TM: Norm, Do you use a new id for an update alert and refer to the id(s) of previous alerts for the same event in the <reference> subelement? I think this is the use case intended in spec. NP: Yes we do but your sentence here is incorrectly written as per that specification. It should be... "Do you use a new id for an update alert message and refer to the id(s) of previous alerts messages for the same event alert in the <reference> subelement?" I think this is the use case intended in spec.
 
If you look at that spec (section 3.1), it is defined as the Message ID, not just id or even Alert ID.  In section 3.2 it says identifier and in the Definition column for it says alert message not alert. So when you see "alert message", message is the object in question, and the word alert is just a qualifier (adjective) to knowing what that message is referring to.
 
So we have message id's and the <references> element refers to alert messages, not alerts.
 
Think of alerts like a "bank account" and a message as a "transaction" on that bank account. The bank account id is the same throughout all the transactions, however the transaction itself has an internal ID the customer rarely ever sees (sometimes when you make an online payment you see the transaction id "for your records" in case there is an issue later to resolve). However in, Public Alerting, it's not the alert id that is important, it's the message. That message is a transaction. The message is valid until it expires simply meaning that it "airs" until it expires.  If it's real time alerting (i.e. what's important going forward), the latest message is really all that counts.
 
So CAP doesn't focus on an Alert, or even defines alert, it focuses on messages. It leaves the definition of Alert up to the issuer and their business of alerting model. So both definitions of alert work with CAP. CAP doesn't discriminate. However, when one says the alert expires, it creates false expectations on the part of the distributers because it may not have expired. The public doesn't care what it means because it is no longer important to them.
 
So with my EC alerts on Google, there are issues, because Google represents Alerts as being the other definition than the one we use (or Jake uses). Your document promotes the a couple of false conclusions as a result when it comes to alerts expiring. The conclusion are correct in certain cases, by happenstance, but it is not universally correct in our opinions.
 
TM: Also, I notice in the spec, that "alert" and "message" are used interchangeably: 
NP: Disagree. Re-read with the above thinking.
 
1.3.1 <alert> 
<alert> segment provides basic information about the current message: its purpose, its source and 
 its status, as well as a unique identifier for the current message and links to any other, related messages. 
NP: (see all about messages, doesn't imply alert is the same thing)

An <alert> segment may be used alone for message acknowledgements, cancellations or other system 
functions, but most <alert> segments will include at least one <info> segment. 
NP: Here we refer to <alert> and there is no confirmation that the segment discussion equates alert to message.
 
I think the doc would benefit by clarifying its usage of terms, since these terms seem overloaded in different jurisdictions. 
NP: They don't define alert deliberately. It's the message that CAP standardizes, leaving alert to the business people out there to define as they see fit. It is guides and practices docs that should define how alert is used in the business. For example, NOAA and EC is one way and the USGS is the other. In CAP, either definition works so they aren't forced to take sides.
 
A few more points: the current doc treats an alert as a single message relating to an event. 
NP: Not the way I read it. If you look at <eventCode> it has an asterisks which implies it could be more than one event, even within one info block. Also, different info blocks could have different events. I could have a Hurricane alert message for Myrtle Beach with one info block talking about Hurricane A just leaving and a second info block about Hurricane B coming in a couple days from now. Not saying it works that way out of NOAA now but it could easily in CAP work that way. So multiple events for a single alert (over several messages). 

TM: And it recognizes that there may be multiple alerts for a single event (with multiple alert updates for an event -- each presumably with its own alert id). 
NP: Yes, but message id, not alert id. 
TM: It also assumes that a single message may contain one or more info blocks to cover different areas or languages for the current alert message (the spec says: "Multiple <info> segments may be used to describe differing parameters (e.g., for different probability or intensity "bands") or to provide the information in multiple languages."). Are these assumptions consistent with how you do things in Canada? 
NP: Yes, we think of each info block as a separate audience message. Each info block serves a segment of the audience, in this case the general public. A single alert can span several messages. Each message can contain several audience messages.
 
I think Jacob is saying that he sees a difference between the "alert" and the "alert information" (they may have different expiration times) but I don't see this distinction in the spec nor does it make sense to me. I do see a distinction between the alert expiration and the event expiration though. 
NP: Hopefully you do now. It is a matter of opinion based on how one defines what an alert is. The USGS defines alerts the way you do. We don't. But it doesn't matter to CAP but it certainly creates confusion to distributers that don't see it both ways.

> Finalize Example Practices: CAP Elements Post-30 day Review Issues
> ------------------------------------------------------------------
>
>                 Key: EMERGENCYADOPT-1
>                 URL: http://tools.oasis-open.org/issues/browse/EMERGENCYADOPT-1
>             Project: OASIS Emergency Management Adoption TC
>          Issue Type: Task
>         Environment: Word Document
>            Reporter: Tony Mancuso
>
> We need to resolve latest issues raised by Jacob Westfall, then resubmit the Committee Note for 15 public review

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira