OASIS Emergency Management TC

 View Only

Re: [emergency] EDXL Target Areas for device coded recipients

  • 1.  Re: [emergency] EDXL Target Areas for device coded recipients

    Posted 05-26-2005 13:24
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: Re: [emergency] EDXL Target Areas for device coded recipients


    Check the attitude at the door, will you, Kon?  This really isn't  
    about you.
    
    Personally, for all the reasons I've explained before, I think it  
    would be an interoperability mistake to encourage building system- 
    specific codes into the targetArea block.  Besides which, in this  
    case it would be misleading, since the router isn't necessarily in  
    the target area.
    
    If you needs specific addressing a mechanism is provided, which is  
    <recipientAddress>.  Or for even more flexibility you could hold your  
    nose and simply use a <keyword>.
    
    - Art
    
    
    On May 25, 2005, at 8:25 PM, Kon Wilms wrote:
    
    > On Wed, 2005-05-25 at 18:12 -0400, Art Botterell wrote:
    >
    >> On May 25, 2005, at 1:06 PM, Kon Wilms wrote:
    >>
    >>
    >>> What if the device receiving the data is not the intended recipient?
    >>>
    >>
    >> Not sure what you have in mind... but if the device has been
    >> programmed to process messages for recipients in a particular area, I
    >> assume it will.
    >>
    >
    > But you haven't addressed content routing devices, and thats what I'm
    > attempting to address. These are intermediary reception devices  
    > that sit
    > at the edge of a network, but do not parse the content. They are  
    > targets
    > for delivery, but the recipients are other systems on their local or
    > next-hop networks.
    >
    >
    >>> This sounds a little half-baked. This is supposed to be a routing
    >>> mechanism, after all.
    >>>
    >>
    >> Gee... could I maybe encourage you to think twice before throwing
    >> around terms like "half-baked"?... it sounds a bit hostile and a
    >> number of folks spent a fair amount of time working on this, so some
    >> of them might take offense. Would you settle for just saying that you
    >> yourself don't fully buy it yet?
    >>
    >
    > Good job on the misquote and the rest of the lame insinuations and
    > fabricated commentary - A+ for effort, F- for tact.
    >
    > Now, if you're done with your whining, lets recap the facts -
    >
    > 1. you gave me a proposal (use a keyword field in the distribution
    > block), and
    > 2. I think that proposal is half-baked.
    >
    > Why? Because the EDXL spec specifically states "<targetArea> elements
    > describing geospatial or political target area for message delivery".
    >
    > Going by this definition, I should use the targetarea to direct
    > reception of messages. But according to you I shouldn't.
    >
    > We can argue this back and forth as many times as we want, but it all
    > boils down to this:
    >
    > Targetarea functionality as it is defined right now will not work for
    > satellite, terrestrial and datacasting distribution and routing of  
    > EDXL
    > content.
    >
    > Why? At the headend, a device is going to encapsulate the data and
    > deliver it. At best one wants to preserve as much of the EDXL  
    > message as
    > possible. The originating message may only have geographical
    > information. The headend system has functionality to perform target  
    > area
    > to device mapping, but where does it store that functionality? Outside
    > of the EDXL message? Most likely. Yet, now you are mixing multiple
    > layers of referenced protocols, defeating the purpose of EDXL, since I
    > may need to retain that information to determine how I received the
    > message.
    >
    > Before you jump up and give me the token 'this sounds like a specific
    > implementation issue' line, I give you this response - our receiver
    > devices have built-in embedded map servers. I can easily use  
    > targetareas
    > of geographical coordinates to target MY devices. However 99% of ALL
    > OTHER satellite and terrestrial devices use the common targeting
    > mechanism of a device identifier, and have no mapping or geo- 
    > capability
    > at all. County and jurisdiction are equally unusable, as they are not
    > granular enough.
    >
    > So I propose -
    >
    > Add an 'identifier' field to the targetarea section, which lets people
    > who cannot target geographically at the 'receiver device level'
    > accomplish their goals.
    >
    > <identifier>
    >   <keyword>
    >     <valueListUrn>valueListUrn<./valueListURN>
    >     <value>value<./value>
    >   <./keyword>
    > <./identifier>
    >
    > (ignore the .'s)
    >
    > where keyword occurs 1..n and identifier occurs 0..n. This would give
    > the most flexibility.
    >
    > Cheers
    > Kon
    >
    >
    >
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  You may a link to this group and all your TCs  
    > in OASIS
    > at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    >
    
    


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