Subject: Re: [emergency] NOAA Undermining International Standards?
On Jun 1, 2006, at 6/1/06 6:12 AM, Rex Brooks wrote: > Thanks for the heads up, Art, Can you provide the specific parts > of CAP that are not being implemented? Rex - What's really tragic here is that the problem would be trivial if it didn't have such lethal potential. First off, let me stress that my concern is NOT with the various NOAA/ Battelle requirements that certain CAP-optional elements be treated as mandatory. (E.g., while one might debate the wisdom of mandating use of the legacy SAME coding on such a massive scale... thus perpetuating SAME's obsolescent and inflexible geographic targeting and slowing the move to true geospatial/location-based alerting... it's still a legitimate "profile" requirement in terms of the CAP specification.) But where HazCollect left the fold altogether was in their unilateral choice not to support the CAP <instruction> element. Which means that a well-formed CAP message, with the hazard description in <description> and the safety instructions in <instruction>, would lose a critical part of its meaning in transiting the HazCollect network. Remove the sender's instructions from a message and people could get killed. The ostensible reason for this is that the existing Weather Radio and EAS delivery systems are limited to two minutes of audio, corresponding to something like 240 written words. The HazCollect answer has been to truncate the <description> field at 240 words and to ignore the content of the <instruction> element altogether. Obviously it would be a simple matter to concatenate-and-trim (or trim-and-concatenate) the two fields, but for some reason NOAA has chosen consistently to make excuses ("not in the original design" / "no money") instead of simply writing the requisite change order. In delving into this with various NOAA and Battelle staff, an underlying concern has surfaced... that the existing NOAA "weather wire" teletype format makes no structural distinction between the informational and "call to action" section of their messages. Why this would matter one way or the other is unclear to me, except possibly as reflecting a desire not to allow anything into HazCollect that would make pre-existing systems look bad by comparison. A subtle but crucial distinction is involved here, between providing for compatibility with legacy systems and imposing the limits of those legacy systems on future technologies. The OASIS Emergency Management Technical Committee and its predecessor, the CAP Working Group, both went to great pains in designing CAP to provide for back- compatibility without sacrificing the design requirements we drew from the social science research on how effective warning systems work. But the real issue isn't a particular design choice, it's a policy under which NOAA seems to be trying to rewrite the CAP specification without consultation or formal process. That goes to the credibility of the entire standards effort. - Art