OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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"

>I must admit that I'm a bit confused by these "talking points." I
wonder if someone could explain a bit more about how CAP "would be
fully compatible with the CEA spec as well as the EAS and Weather
Radio specifications that 'Public Alert' extends."

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. But it still has to get stripped out into a different format at
the transmission headend prior to transmission, and none of the weather
radio receivers understand CAP *let alone* XML (these are made to be cheap
and reliable, not expensive and compatible). I personally see the inclusion
of weather radio devices in certain television brands as nothing more than a
cheap marketing ploy following 9/11. Indeed with digital television, these
type of integrated devices are worthless, since every broadcaster can use
the digital transmission signal to deliver this data (and much more).

>themselves incompatible. Or, am I missing something? Note: There was a
similar message posted on the list a few days ago that said that CAP
was somehow "compatible" with the existing NWS message system. (As is
demonstrated in one of the CAP V1.0 examples, it is certainly clear
that an NWS message, which is not in a form that would traditionally
be called "compatible" with CAP, can be transformed into a
CAP-compliant form.)

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. Yes
the NWS provides CAP messages on their website. But that's a test feed, and
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).

When taking the existing products and converting to CAP, the best you can do
is sort-of-approximate some values, and then stuff the entire blob of the
message into a CAP message's alert details field. The alternative is to
write a parser for each product - around 3000+ total. I've tried this (one
generic parser, mind) and even with regex parsing I can't 'guarantee' that
everything is parsed or stuffed into the CAP message correctly. Regardless,
reformatting is regex and stringcompare hell. 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. One requires a
higher datarate, or in-line compression. Indeed, for the transmission I do,
any text or XML is dynamically gzipped.

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.


Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@nds.com and destroy the original message.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]