[CAP] CAP 2.0 proposal

Wed Mar 19 04:55:02 PDT 2008

Sorry for the delayed response folks - I drafted this and ended up stuck on some urgent and important items.  This is quite an important issues, so I am weighing in.

We have been through a similar debate with some federal agencies that use our kit for distributing CAP messages.  The net result of the debates was that the burden for determining the significance of an update lies on the recipient.  The logic is this:

I may update my CAP alert and I may consider a change significant, but I have no knowledge of whether you would agree.  Assuming the recipient has been following the chain of alerts (initial alert, followed by the chain of updates, then the termination) then the recipient can examine each alert, note the difference and determine whether the updates are significant to their own situation.

Let's consider the following scenario - we have some conditions where an agency is sharing out information about a potential hazardous airborne chemical incident.  The information may be vague (low level of map detail for example) in the beginning as they make approximations of a potential contamination plume for example.  As an incident progresses and they refine their model (quantity of material is known, leakage rates, weather conditions) they can issue updates on their plume that are more and more refined.  The modelers would consider each update to be significant, but a first responder may not.  The first responders usually take the more cautious approach and wants to evacuate a large area to ensure that changes in conditions on the ground are already handled before a model update.  The recipient in this case needs to examine each update (typically the last message is examined) and they determine whether that update is significant (e.g. plume has reversed direction, or is larger than the current evacuation zone.)  The sending agency cannot make that decision for them, except in rare times that standard operating procedures fully define that decision mechanism.

This is a tough nut to crack.  Our guidance is to present the information to the local decision maker when appropriate and let them decide if the update is significant or not.  CAP isn't about telling people what to do, it is about sharing information that may be relevant to the recipient.  Showing history of the messages along with a "diff" of the changes helps here.

I hope that helps, though from my experience this is a rather contentious issue.  

Cheers,  

Darrell

Darrell O'Donnell, P.Eng.
Chief Technology Officer
Black Coral Inc.
www.blackcoral.net
darrell.odonnell at blackcoral.net
p: +613.216.8833 x221
m: +613.866.8904 

-----Original Message-----
From: cap-list-bounces at lists.incident.com [mailto:cap-list-bounces at lists.incident.com] On Behalf Of Jim Trawick
Sent: Thursday, March 13, 2008 12:22 PM
To: cap-list at lists.incident.com
Subject: Re: [CAP] CAP 2.0 proposal

It's not the quantity of change, it's the nature of the change that I
believe needs to be delineated, and only the inputter knows that. Adding a
paragraph or two on the history of the building which is on fire might be
appropriate in an "Update" msgType, but it doesn't change the substance of
the warning. A single-letter change might move the warning to another state.
And the human stochastic will make those things happen from time to time,
and depending on personal discipline is optimistic, at best.

Adding a profile extension will make it optional, and lack of this
capability requirement has resulted in many "That won't work for us" answers
in discussions I've had with people who really need to be using this
standard. Let's tie it down so they can.

I'm not bound to counters, or any other particular methodology. What CAP
remains to need is:

  "Any programmatic methodology to distinguish updates to the substance of
the warning from updates to the text of the warning"

No excuses. No broad-brush hand-waving. No pontificating or turf defense. No
pointing to inappropriate fields. No expecting someone else to change their
evil ways. A methodology, preferably a simple, elegant one.

	Jim T

-----Original Message-----
From: cap-list-bounces at lists.incident.com
[mailto:cap-list-bounces at lists.incident.com] On Behalf Of
cap-list-request at lists.incident.com
Sent: Tuesday, March 11, 2008 3:00 PM
To: cap-list at lists.incident.com
Subject: CAP-list Digest, Vol 23, Issue 3

Send CAP-list mailing list submissions to
	cap-list at lists.incident.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://eastpac.incident.com/mailman/listinfo/cap-list
or, via email, send a message with subject or body 'help' to
	cap-list-request at lists.incident.com

You can reach the person managing the list at
	cap-list-owner at lists.incident.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CAP-list digest..."

Today's Topics:

   1. Re: CAP 2.0 proposal (Mick Jagger)

----------------------------------------------------------------------

Message: 1
Date: Tue, 11 Mar 2008 12:19:37 -0400
From: Mick Jagger <lists at jpw.biz>
Subject: Re: [CAP] CAP 2.0 proposal
To: cap-list at lists.incident.com
Message-ID: <20080311121937.1886e633.lists at jpw.biz>
Content-Type: text/plain; charset=US-ASCII

Hi,
	I believe the solution to Jim's problem of determining when a
substantive change has been made versus a minor correction for spelling
errors is solved by 2 features of the current CAP 1.1 spec.

The first is proper use of the msgType and references elements.  This way a
feed consumer can compare the difference between the previous message and
the new message and see that only 1 character changes in the description.
Key to this feature working is that the feed publisher must keep original
messages intact so that comparison can take place.  Overwriting the previous
message with the new message, then referencing the previous message which
can no longer be accessed, is causing the problem.

The second is the use of a CAP profile/extension.  This is something the
OASIS group needs to outline but it doesn't require any changes to the spec,
just clarification.  However valueListURN would be a very useful addition to
a future version of CAP.  An extension defines some optional elements such
as parameters, eventcodes and geocodes and their values.  So the NWS would
define and publish their own extension.  In the extension could be a
parameter value list for the changes that are made to a message's content,
so valueName = contentChange and value could be a list that includes things
like spelling, missing data, language translation error (Canadian extension
includes this already), oops my bad, etc.  When a minor change is made that
is non-substantive, the creator could check a box that corresponds to the
reason and the extension parameter is added to the message allowing readers
to parse it accordingly.

-- 
lists at jpw.biz
--

------------------------------

_______________________________________________
CAP-list mailing list
CAP-list at lists.incident.com
http://eastpac.incident.com/mailman/listinfo/cap-list

End of CAP-list Digest, Vol 23, Issue 3
***************************************
_______________________________________________
This list is for public discussion of the Common Alerting Protocol.  This list is NOT part of the formal record of the OASIS Emergency Management TC.  Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
CAP-list mailing list
CAP-list at lists.incident.com
http://eastpac.incident.com/mailman/listinfo/cap-list

This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself.