MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Talking Point re CAP and CEA "Public Alert"
Art Botterell wrote:
> We're the new guys on the block, and we're taken pains
> to be compatible with the old established systems.
There is that "compatible" word again... I was surprised to
see it at the bottom of Art's message since everything up to that
point seemed to be acknowledging that CAP *was not* compatible with
existing systems and explaining why it wasn't compatible. (Note: Not
being compatible is *not* a negative thing. It is just a statement of
fact.)
So, can you please explain what is meant by "compatible"? The
usage here is foreign to me and doesn't seem to conform to either my
experience or the definitions given in the dictionaries that I use.
Perhaps there is some intent to indicate a non-syntactical
compatibility. i.e. While the syntaxes, message formats, etc. are
incompatible, there is some attempt to remain "compatible" in terms of
concepts, philosophy, etc. Is this what you're getting at? If so, I
think it would be better to say that. "Compatibility" in the computer
business is usually a question of syntax and format -- not concept. My
concern is that if this apparently "unusual" usage of the word
"compatible" continues, people may come to think that the CAP TC is
making promises that can't be kept. Or, they might just assume that it
simply is not much of an advance over what has been traditionally
available. (i.e. if CAP *was* compatible with EAS, etc. then it
*couldn't* be very different from them.)... This would not be good.
bob wyman
-----Original Message-----
From: Art Botterell [mailto:acb@incident.com]
Sent: Thursday, April 08, 2004 7:03 PM
To: emergency@lists.oasis-open.org
Subject: Re: [emergency] Talking Point re CAP and CEA "Public Alert"
At 2:19 PM -0700 4/8/04, Kon Wilms wrote:
>The only compatibility I see is that at some point in time the Public
>Alert message elements can be stuffed into a CAP message for
transport
>on headend networks.
Right now that's right. It's a backward compatibility challenge that
we're addressing at the content level. And saying CAP is compatible
with Public Alert (or NWR, or EAS) is not the same as saying the
reverse.
Obviously it's going to take more than a couple of weeks for the
existing public warning infrastructure to convert to CAP.
Fortunately (and by design) it's not an all-or-nothing proposition.
And looking at it politically, if we want uptake for CAP, seems like
we may want to avoid appearing to detract from any of the major
existing players. Instead, we may want to emphasize how CAP can make
existing systems even better. Over time, I'm confident the benefits
of CAP will become clear to everyone and its use will become more
pervasive.
>It isn't compatible with the NWS system from the point where one can
>just take an NWS message like EMWIN products and stuff them into a
CAP
>file.
True, because NWS doesn't enforce strict structures for their text
products. The current NWS text system comes from a tradition of
"rip-and-read" teletype copy meant for human reading, not for easy
computer processing.
NWS management are well aware of the huge variations in how different
forecast offices format their products, but it's a huge organization
and change takes time. Besides, until now there wasn't an industry
standard available... and the current administration is very much
oriented toward industry-generated standards.
There's been progress: The LAT...LON convention for describing
precise target area coordinates in "short fuse" warning products is
being used pretty consistently... and the "bullet" format used by a
number of offices for warnings can be mapped fairly precisely into
the component elements of a CAP document. And their experiment using
CAP suggests that NWS is actively considering moving to more
structured formats.
But in the meantime it's a little like copying VHS to DVD... the
output product can't be any better than the input. The best we can
do is make sure that we can accurately reflect the input, however
structured or unstructured it may be.
>I don't see any CAP compatible files coming over the GOES satellite
>feeds (thats the real stuff I care about - test feeds are good for
demo
>only).
NWS has a whole process they have to go through to adopt new
technology. The first step is an "experimental" service, which is
what they're doing now. So if you want CAP feeds by satellite, I'd
encourage you to communicate your support to Bob Bunge in the NWS
CIO's office (<robert.bunge@noaa.gov>) so he'll have ammunition to
persuade his management to take that next step.
>CAP and XML in general is also
>too wordy to transmit quickly at a low datarate - the 3000+ products
>that are transmitted at 2400 and 9600bps over GOES would never come
>through in a timely fashion if they were all reformatted to CAP spec.
This objection comes up regularly... but as you've demonstrated, XML
compresses really well, and that's a fairly routine, standards-based
solution.
>CAP is only compatible with the NWS system when the NWS decides to
>reformat all their products to CAP and starts distributing them over
>their satellite feeds. This is just my opinion, however.
Get your point, but I think that may be putting the shoe on the wrong
foot. We're the new guys on the block, and we're taken pains to be
compatible with the old established systems. We can hope to see a
migration toward more modern methods as the benefits of CAP are
demonstrated, and as consumers start asking providers to make the
move.
- Art
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_w
orkgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]