Re: [emergency] Proposal to extend the EDXL TargetArea to allow more flexible targeting/filtering/content routing

[Art Botterell <acb@incident.com>]

No, no, Renato... my post wasn't about your note at all.  Rather I  
was responding to the original proposal per the subject of this  
thread.  The points of clarification you suggest are all worth  
discussing, but instead we seemed to be rushing toward a substantive  
change to the spec that, in my opinion, would only deepen the confusion.

And I guess I should point out that this process did start out with  
use cases and requirements, although that may have been before you  
joined us.  In particular you might want to review the Statement of  
Requirements we accepted from the Emergency Interoperability  
Consortium... <http://www.oasis-open.org/apps/org/workgroup/emergency/ 
download.php/11163/EDXL%20Routing%20Block%20Requirements%201-25-05% 
20mods.doc>.

It must be difficult from your location to keep abreast of processes  
that have relied on conference calls and face-to-face meetings for so  
long.  Please be assured that a lot of your concerns have, in fact,  
been brought up before.

- Art

On May 31, 2005, at 5/31/05 5:14 PM, Renato Iannella wrote:

>
> On 31 May 2005, at 06:18, Art Botterell wrote:
>
>
>> My impression is that this proposed change, well-intentioned  
>> though it surely is, would be both unnecessary and harmful.
>>
>
> Art - you have over-interpreted my posting. My intent was to  
> provide more insights in the
> use-case and requirements for EDXL. As it stands today, the EDXL  
> draft is not clear on the
> purpose - for example (on page 1) the <targetArea> is only  
> described as being the "target area for
> message delivery". The definition for <recipientAddress> (page 3)  
> includes "individual" and is not clear
> if this covers a group of people or a device/service.
>
>
>> Unnecessary because it really just duplicates the existing  
>> <keyword> structure under a different name within the <targetArea>  
>> block.
>>
>
> No. I assumed nothing about where elements should appear.
>
>
>> And harmful because it would sanction the use of system-specific  
>> (i.e., not universally understood) codes as aliases for geospatial  
>> descriptions.
>>
>
> No, these were just "use case" examples. I fully support use of  
> international standard codes.
>
>
>> I'm afraid this proposal is based on a misunderstanding of  
>> <targetArea> as the only part of the EDXL Distribution Element  
>> (DE) that describes the target audience.  That's simply not the case.
>>
>
> That is not true. I fully understand the scope of the <targetArea>  
> element, and I did not even propose any changes to this.
>
>
>> The suggestion that the existence of intermediate routing devices  
>> somehow requires the proposed change also seems misguided.  The  
>> whole purpose of the DE is to allow senders to describe where they  
>> want the enclosed content to go without needing to specify how  
>> each particular transport system will route it, which is something  
>> they may not know and may not even be permitted to know (e.g.,  
>> within secure networks.)
>>
>
> True, and nothing in my posting treats "intermediate routing  
> devices" differently.
>
>
>> As an alternative, in the interests of avoiding unnecessary  
>> duplication and not diverging from geospatial standards, I'd like  
>> to propose that <recipientAddress> be relabeled  
>> "<explicitAddress>" in order to clarify that it can refer to any  
>> recipient device, whether it's an end-point or a relay (since as  
>> noted above, the sender may not always know, or need to know,  
>> which it is)... and also that we consider whether  
>> <explicitAddress> should have a domain/value substructure  
>> consistent with <keyword>, <recipientRole> and <senderRole>, in  
>> order to deconflict addresses from various systems.
>>
>
> What about <targetAddress> to mirror <targetArea> (and perhaps even  
> <targetKeyword>)
>
>
>> All this is in pursuit of the rule of parsimony, aka the "KISS*  
>> Principal."  It would be easy to address each individual use-case  
>> by tossing more features into the spec, but that's the road toward  
>> incoherence and bloat.  Our first question should always be "is  
>> there a way to solve this within the existing structures?"  In  
>> this case the answer is "yes."
>>
>
> I think this is the wrong approach. We should have *started* with  
> the use cases and requirements, then develop
> the semantic and technical solution. The current situation is one  
> where we have an "existing structures" and
> we are trying to work out if it meets requirements that we have not  
> now articulating.
>
> BTW, terms like "unnecessary", "harmful", "misguided" are very  
> powerful and should be used with care ;-)
>
> Cheers...
>
> Dr Renato Iannella
> Project Leader, NICTA, Brisbane, QLD, AUSTRALIA
> P: +61 7 3000 0484 F: +61 7 3000 0480 M: +61 4 1313 2206
> E: renato@nicta.com.au W: http://nicta.com.au
>
>
> ---------------------------------------------------------------------- 
> ----
> This email and any attachments may be confidential. They may  
> contain legally
> privileged information or copyright material. You should not read,  
> copy,
> use or disclose them without authorisation. If you are not an intended
> recipient, please contact us at once by return email and then  
> delete both
> messages. We do not accept liability in connection with computer  
> virus,
> data corruption, delay, interruption, unauthorised access or  
> unauthorised
> amendment. This notice should not be removed.
>
> ---------------------------------------------------------------------
> 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
>