[CAP] CAP 2.0 proposal

Jim Trawick JimTrawick at viaRadio.com
Thu Mar 13 09:22:04 PDT 2008


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


More information about the CAP-list mailing list