EM Messages and Notification SC

 View Only
  • 1.  Re: Message coding

    Posted 10-03-2003 23:12
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency-msg message

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


    Subject: Re: Message coding


    I absolutely agree, Allen... we can improve.  I think that's what 
    we're all trying to do.   That's why specific, actionable suggestions 
    are so important.
    
    At the same time, I think we also understand that we could wait 
    forever trying to achieve perfection... and still not get there, 
    because a lot of what we need to learn we'll learn only by 
    experience... as illustrated by Jeff's notes based on his real-world 
    implementation work.
    
    Anyway... Allen has invited us to transfer our conversation about the 
    CAP message format onto the open 
    "emergency-msg-comments@lists.oasis-open.org" list.  Allen, can you 
    please brief the non-OASIS members among us on how to join that list?
    
    Thanks!
    
    - Art
    
    
    At 5:42 PM -0400 10/3/03, R. Allen Wyke wrote:
    >I *think* I can help here. Jeff, please correct me if I am wrong on my
    >assumptions of what you are asking.
    >
    >I think what you are bringing up is that there are 1,000 different ways
    >to technically do this - we all agree there, but that is not the real
    >root of the issue. The issue is, what is the "right" way to do it? More
    >specifically, what, from a standards perspective, is the correct way to
    >process and therefore support CAP messages? That is what developers what
    >to know, and it is something the spec should avoid ambiguity on and
    >around.
    >
    >>From a standards (MSG SC) perspective, the focus is on how to answer
    >Jeff's question, but also have it apply to the widest target audience
    >possible. How do we address not only Jeff's scenario, but also Frank,
    >Tom, Sarah, and Bob's?
    >
    >The take away from these comments is that we need to add some
    >clarifications to CAP. These can come in the form of normative or even
    >non-normative additions to the spec, or perhaps to supporting documents
    >(like the guidelines, or maybe a "CAP for Oneway Systems" or "CAP for
    >Web Services" or "CAP for Subscription-Based Processing" or...you get
    >the idea).
    >
    >Think of it this way. If the entire TC was hit by a bus, is there enough
    >information in the CAP spec to tell target implementors how to implement
    >the standard and share CAP alerts? Based on these comments (they are
    >GREAT btw!!!), I think we can improve here.
    >
    >Allen
    >
    >On Fri, 2003-10-03 at 17:27, Art Botterell wrote:
    >>  At 3:42 PM -0500 10/3/03, Jeff Kyser wrote:
    >>  >And even saying you must use at least one of:
    >>  >	FIPS/SAME
    >>  >	ZIP CODE
    >>  >	polygon
    >>  >	circle
    >>  >would give most/all of us the opportunity to parse a CAP message in
    >>  >a predictable way.
    >>
    >>  Since that would involve implementing some IF-logic anyway, would it
    >>  be hard to simply treat an <area> with no geospatial or geocode
    >>  elements as equivalent to no <area> at all?
    >>
    >>  It's generally true that different receivers will have different
    >>  capabilities, so if a sender has a broad audience in mind it's in the
    >>  sender's interest to provide as much detail as possible.  What we've
    >>  hesitated to do is prevent senders from sharing what information they
    >>  have, just because they don't have as much as we'd like.
    >>
    >>  Currently we permit the inclusion of an <area> block with only an
    >>  <areaDesc> inside.  That's to ensure support for captioning and
    >>  text-to-audio applications and to cover cases where the description
    >>  is something like "downtown St. Louis" and the sender doesn't have
    >>  GIS or geocode data readily available.
    >>
    >>  One reason for the <geocode> element was to permit the inclusion of
    >>  one or more system-specific alerting zone codes.  If we required that
    >>  the <geocode> had to be a FIPS code, a SAME code (they aren't exactly
    >>  the same, as you know) or a ZIP code, that would preclude including
    >>  system-specific codes.  Would that be appropriate from your point of
    >>  view?
    >>
    >>  Honest, Jeff, I'm not trying to bust your toes.  I'm just trying to
    >>  understand your concerns clearly, and to share with you some of the
    >>  concerns that have come up in the past, so what we carry back to the
    >  > formal process can be as useful and effective as possible.
    >>
    >>  - Art
    >>  _______________________________________________
    >  > CAP-Interop mailing list
    >>  CAP-Interop@lists.incident.com
    >>  http://www.incident.com/mailman/listinfo/cap-interop
    >>  This is a discussion list for people involved in testing and 
    >>evaluating interoperability of applications using the Common 
    >>Alerting Protocol (CAP).
    >--
    >R. Allen Wyke
    >Chair, Emergency Management TC
    >emtc@nc.rr.com
    >http://www.oasis-open.org/committees/emergency
    >
    >
    >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-msg/members/leave_workgroup.php.
    
    


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