[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"
On Apr 10, 2004, at 5:23 PM, Art Botterell wrote: > Of course context is important. That's why I'm suggesting we not try > to apply technical definitions beyond their appropriate context. We > need to remember that the rest of the world uses many words > differently. Keep in mind that our world (aka target audience) are developers, not end users per se, therefore we must talk in developer-speak. Bridging the gap with end users, so that they also know the importance of an effort, is done through FAQs, fact sheets, and other supporting outreach guides. > As a practical matter I believe the general public understands > "compatible" to mean "won't interfere." And most direct stakeholders > (emergency managers, product marketers, elected officials) really take > "compatible" to mean "won't make my existing product, system or > program less valuable, or make my prior decisions look bad." We can > use more rigorous definitions within our technical community, but > most folks have mundane concerns. And if they're interested in the > technical details, those are all available. Woooo. The "general public" and what is defined as the stakeholders above is not our concern, as it pertains to the standard, so their definition is irrelevant (except in the outreach/marketing material mentioned previously). People writing code is our concern, and the accepted definition of "compatible" is not "won't interfere", but rather something like "will interact and work together...if you want it too." > As for "interoperability"... CAP is a content standard, not a system > architecture. Interoperability depends on how and where CAP is > used.... just like interoperability of voice radios depends on a whole > set of factors... frequency, modulation scheme, network architecture, > content format, management procedure and so on. > > For example, voice radios can operate on different frequencies and > still interoperate if the network architecture (a repeater or a > cross-channel patch) links them. So are they "reeeeeeeeally" > interoperable? Below the functional level the question rapidly loses > meaning, especially for end-users whose only goal is getting messages > from A to B. While I understand your example and agree that CAP is a content standard and not a system architecture, I don't think that is the point (applying wrong definition of interoperability - you are thinking communication protocol). Any standard that is planned to be used across multiple systems must consider the message interoperability challenges. For CAP, the areas of inline binaries, putting multiple "alerts" (ie: info blocks) in a single message and how those should be processed, etc. are interoperability issues, and as you can see, they have nothing to do with the actual exchange (ie: HTTP, sneaker-net, etc.). > Anyway, this isn't really a TC issue, it's more of a PR and/or > marketing concern... unless the TC proposes to go into the > compatibility certification business, which I think we'd decided not > to do. I was just offering a personal informational suggestion in > case anyone got blindsided by this issue. Nothing normative or > mandatory about it. Guidelines for compatibility, and our own internal discipline for interoperability are the real issues here, and both of these result in "work product" of the TC. > - Art > > > > > At 11:13 AM -0400 4/10/04, Walid Ramadan wrote: >> Art, I beleive the context is actually extremely important. It looks >> like "compatible" is being used to imply that CAP can "interoperate" >> with those other systems, but not "reeeeeeeeally" interoperate with >> them. So which way is it? Does it or does it not? I believe the >> introduction of terms such as "co-exist", "constructive", and >> "relatively" to define "compatible" is only making the definition of >> "compatible" more elusive. And given that the folks you listed are >> not tech-savvy, how do we ensure that their definition of >> "compatible" is, to use your term, "compatible" with ours? Could it >> be that in their minds, compatible means fully interoperable? >> >> Walid >> >> -----Original Message----- >> From: Art Botterell [mailto:acb@incident.com] >> Sent: Thu 4/8/2004 9:57 PM >> To: bob@wyman.us; emergency@lists.oasis-open.org >> Cc: >> Subject: RE: [emergency] Talking Point re CAP and CEA "Public Alert" >> >> >> >> Bob, do any of us really have time to split hairs about the word >> "compatible" in this context? >> >> The folks at the Weather Service, the folks at the FCC and the folks >> at CEA have all expressed satisfaction that CAP is compatible with >> their existing systems... in that they can co-exist and interoperate >> in a constructive and (relatively) convenient way. (Please remember >> that most of the policy- and decision-makers involved in warning >> systems aren't computer-business folk and don't necessarily use words >> in their most technical sense.) >> >> Of course, if you aren't comfortable using the word, you don't have >> to. And if you'd like to offer a suggestion of a better word, feel >> free. >> >> - Art >> >> >> >> At 8:16 PM -0400 4/8/04, Bob Wyman wrote: >> >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. >> > >> > >> >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_workgroup.php. >> >> >> 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_workgroup.php. >> >> > > > 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_workgroup.php. > > -- R. Allen Wyke Chief Technology Officer awyke@blue292.com 919.806.2440
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]