OASIS Emergency Management TC

Re: [emergency] Talking Point re CAP and CEA "Public Alert"

  • 1.  Re: [emergency] Talking Point re CAP and CEA "Public Alert"

    Posted 04-12-2004 14:18
     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"


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