[CAP] CAP 2.0 proposal

Mon Mar 3 14:25:06 PST 2008

If "all of the fields required to discern this are already in CAP", what are
they? If anyone's looked, they're not in the cookbook. I've got the 1.1 spec
in front of me, and nothing in it delineates a corrected community name (and
someone else that needs to be warned) from a re-placed comma.

What little there is in the cookbook is simplistic, at best, and the point
is how it's really being used, not trying to make the real world conform to
our image. There are folks really using it, and in volume. Information in a
real emergency is never going to be accurate until after it's over, so we
need to work with it as it is. These are good folks doing their best to do a
good job. If the tools don't lead them in the right direction, and they all
seem to be headed in the same direction, the tools need to change.

Knock Herb if you want, but weather is what our folks are universally
interested in, and it's what his behemoth, alone, provides. Herb is herding
cats, and no matter how hard he pushes, it isn't going to change this year,
or next. I have to warn people today, and use what I have. Even if he
eventually conforms 100%, I still don't see how that helps me to solve this
problem.

And the real culprits are not the folks in this list, it's those who
guarantee that every time I fetch a warning through their index, it looks
brand spanking new. I'm looking for a way to let them do their thing
(because I can't force them to do anything, either), and still get changes
to my limited bandwidth without completely re-parsing every file every time.

If someone has an idea to solve this problem, I'm interested.

-----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: Monday, March 03, 2008 3:00 PM
To: cap-list at lists.incident.com
Subject: CAP-list Digest, Vol 23, Issue 1

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. CAP 2.0 proposal (Jim Trawick)
   2. Re: CAP 2.0 proposal (Mick Jagger)
   3. Re: CAP 2.0 proposal (Mick Jagger)

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

Message: 1
Date: Mon, 3 Mar 2008 10:41:14 -0500
From: "Jim Trawick" <JimTrawick at viaRadio.com>
Subject: [CAP] CAP 2.0 proposal
To: <cap-list at lists.incident.com>
Message-ID: <000701c87d45$04438b50$0ccaa1f0$@com>
Content-Type: text/plain; charset="us-ascii"

For us (and others I've talked with), one of the key problems in automating
the ingestion of CAP warnings (or other warnings, for that matter) is
discerning when a warning needs updating, i.e., when does an old warning
become a new warning, without becoming a new event (expected duration
change, affected areas added/removed, etc.). The "sent" sub-element is
commonly updated whenever a warning is fetched from its provider's database,
or never updated, rendering it virtually useless for such processing.

To that end, it would be useful to us to have something like a counter
sub-element in the "alert" element near the "identifier" sub-element, which
increments only when substantive changes are made to the warning content,
which for sake of discussion I'll call "CriticalContentRevNumber", and
another counter which increments when non-substantive changes are made to
the warning's wording, spelling or format, which I'll call
"OtherContentRevNumber". "CriticalContentRevNumber" would be a required
entry, and would require a major revision (CAP 2.0) and would obviate
calling it CAP 1.2. "OtherContentRevNumber" could be either required or
optional.

These fields would be input by the warning's originator only, who would be
responsible only for determining whether, in their judgment, the change
affected the "who, what, where, when" content of the warning.

Jim Trawick
Senior Software Engineer
viaRadio Logo Scaleable smaller no tag no background

viaRadio corporation

3153 Skyway Circle, Suite 102
Melbourne, FL 32934-7369
321-242-0001 x113

 <mailto:robina at viaradio.com> JimTrawick at viaRadio.com

This email contains PRIVILEGED AND CONFIDENTIAL information intended only
for the use of the addressee(s) named above. If you are not the intended
recipient of this email, or an authorized employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
dissemination or copying of this email is strictly prohibited. If you have
received this email in error, please notify us by reply email and delete
this email from your records. Thank you for your cooperation.

[demime 1.01d removed an attachment of type image/png which had a name of
image001.png]

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

Message: 2
Date: Mon, 3 Mar 2008 11:26:20 -0500
From: Mick Jagger <lists at jpw.biz>
Subject: Re: [CAP] CAP 2.0 proposal
To: cap-list at lists.incident.com
Message-ID: <20080303112620.136cae21.lists at jpw.biz>
Content-Type: text/plain; charset=US-ASCII

> For us (and others I've talked with), one of the key problems in
automating
> the ingestion of CAP warnings (or other warnings, for that matter) is
> discerning when a warning needs updating, i.e., when does an old warning

All of the fields required to discern this are already in CAP.  The problem
you are facing is that the CAP sources you are looking at do not conform to
the standard.  You are probably looking at the NWS CAP feeds as your example
source and this is where the contentrevnumber solution would be useful.
Hopefully this will be rectified soon with the NWS updating their CAP feeds
and the problem you are facing will go away.

Can I make a suggestion for the CAP cookbook pages.  Since none of the
example CAP feeds that are listed on the cookbook page are publishing valid
CAP messages, can a notation be put beside each of them stating this?  It is
very confusing for new users of CAP to see bad implementations as their
first example.

Also, are there any other public CAP feeds that ARE valid, that should be
added to the Cookbook pages as examples?

Finally, would it also help if reference feed examples were created?  A live
feed could be created  automatically every day following a set pattern with
example CAP messages that could be used for testing.  For example at 9am a
lower level alert is issued, followed by a higher level update with a change
in area at 12pm and cancelled at 3pm.  Also some scenario feeds could be
created that followed real life events and are kept as historical examples.

-- 
lists at jpw.biz
--

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

Message: 3
Date: Mon, 3 Mar 2008 12:13:40 -0500
From: Mick Jagger <lists at jpw.biz>
Subject: Re: [CAP] CAP 2.0 proposal
To: cap-list at lists.incident.com
Message-ID: <20080303121340.39e444b1.lists at jpw.biz>
Content-Type: text/plain; charset=US-ASCII

> Can I make a suggestion for the CAP cookbook pages.  Since none of the
example CAP feeds that are
> listed on the cookbook page are publishing valid CAP messages, can a
notation be put beside each of
> them stating this?  It is very confusing for new users of CAP to see bad
implementations as their first
> example.

I didn't mean to flame any of the current sites listed on the cookbook page,
so I thought I should follow up with some reasons why each feed has
problems.

USGS Feeds - using CAP 1.0 and therefore has problems using Update and
Cancel type messages.  The references field was poorly defined in CAP 1.0
making establishing proper message chains very difficult.  Regular Alert
type messages on the feed are valid and if all the messages are Alerts then
the feed is good.

NWS Feeds - using CAP 1.0 and multiple info blocks versus a feed format.
Invalid fields like identifier and problems with Update and Cancel types
using references.

NWS Tsunami Feed - using CAP 1.0 and no feed format.  Invalid date types
used and problems with Update and Cancel types using references.

EDIS Feed - EDIS is using CAP 1.1 now and the feed link on the cookbook page
is wrong.  EDIS currently has problems with duplicate messages appearing in
the feed and does not use the references field properly for Update and
Cancel messages, meaning you cannot establish message chains.

JRC GDAS Feed - no longer exists.  I believe the replacement for this feed
is http://www.gdacs.org/ which does offer CAP messages.  However these
messages have invalid date types, the odd use of CDATA in descriptions,
invalid area blocks, and problems with Update and Cancel types using
references.

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