OASIS Emergency Management TC

Re: [emergency] Poster for NAWS Participation

  • 1.  Re: [emergency] Poster for NAWS Participation

    Posted 03-23-2006 07:30
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: Re: [emergency] Poster for NAWS Participation


    Seems like we ought to take care here to distinguish between apples  
    and oranges, and between fruit and a fruit truck.
    
    CAP offers a "Platonic ideal" of a warning message, independent of  
    any particular delivery framework, and based on social science  
    research into the effectiveness of public warnings, not on any  
    particular technology.  Its purpose is to provide an interoperability  
    layer that can bridge the vast patchwork of more transport-specific  
    encoding schemes being used in public warning, including free text,  
    SAME, geo-RSS, recorded audio, Braille, etc., etc.  It's been adapted  
    in some cases to contain non-public information, which might be a  
    tribute to the robustness of its design, but may also have caused  
    confusion in some circles.
    
    EDXL, on the other hand, has no inherent content at all, at least so  
    far.  The DE is only an envelope for some other XML content, which  
    might be CAP or might be some other document structure drawn from  
    some entirely different problem domain, such as the proposed RM.  So  
    it's not precisely accurate to speak of "either CAP or EDXL"... the  
    two aren't alternatives, they're on entirely different layers of the  
    network stack.
    
    Likewise, any binding between the EDXL-DE and a particular transport  
    environment involves all the discovery, routing, queuing,  
    reliability, and other network issues of the layers below.  Some of  
    the requirements for that particular stack may be the same for  
    sensors and other operational messaging as they are for public  
    warning, but some may be different.  That's why I asked the question  
    of how broadly or narrowly Dave meant the words "alert and warning"  
    on his poster.
    
    - Art
    
    
    On Mar 22, 2006, at 3/22/06 6:58 PM, creed@opengeospatial.org wrote:
    
    > Just to follow on.
    >
    > Projects such as NAWS are highly relevent to specific domains, such as
    > Homeland security.
    >
    > However, as Art and David both both point out, the vast majority of  
    > alert
    > applications will use widely different distribution mechanisms,  
    > such as
    > reverse 911, and may not use either CAP or EDXL but will use simple  
    > text
    > messaging or georss or other mechanisms. There are already deployed
    > applications doing weather alerts to cell phones.
    >
    > In many of these instances, either CAP or EDXL may be the originating
    > alert message that triggers use of other citizen alerting  
    > mechanisms. In
    > any and all cases, this dialogue once again points out how  
    > important it is
    > that both CAP and EDXL remain implementation and infrastructure  
    > neutral
    > and not tied to any specific information (or dollar) community.
    >
    > My missive for Wednesday evening.
    >
    > Regards
    >
    > Carl
    >
    >
    >> Art
    >>
    >>
    >>
    >> Just like the Internet carries multiple networks with various  
    >> degrees of
    >> separation, the EDXL-DE routing capabilities may/could be used for  
    >> all
    >> types of EDLX-DE information exchanges.  You are right in  
    >> observing the
    >> National needs for this capability as extremely high.  Also, there  
    >> is no
    >> funding for a general open routing framework.  Local direct  
    >> distribution
    >> Point to Point EDXL-DE information exchanges can still be  
    >> accomplished
    >> by numerous methods.
    >>
    >>
    >>
    >> David E. Ellis
    >>
    >> Information Management Architect
    >>
    >> (505) 844-6697
    >>
    >>
    >>
    >>
    >>
    >>