Re: Multiple Addresses in an EPR

John Kemp wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>ext Martin Gudgin wrote:
>  
>
>>I thought the CR phase was about figuring out whether the spec could be
>>implemented 'as written'...
>>    
>>
>
>Isn't it also about figuring out whether the spec. is interoperable for
>reasonable usage? I've heard a reasonable usage expressed that isn't
>supported interoperably by WS-A.
>  
>
The requirement can be met within the scope of the current specification 
(as David Orchard points out), or at a higher level by publicising 
multiple EPRs. OK, it may be slightly inefficient in some (limited?) 
scenarios, but it is guaranteed to work in all scenarios. By adding 
something to the baseline specification that happens to work in the case 
where only the URI changes between "different" EPRs without being able 
to determine a priori that this is the reasonable scenario (which is 
strongly doubt given what I've seen in current implementations) risks 
cluttering it with potentially long-term useless capabilities.

I'm not saying that we shouldn't consider supporting this functionality. 
I am saying that it doesn't belong at this stage at the moment, for many 
reasons, not least of which is that there simply isn't enough long term 
implementation experience to say what is the best approach. Let's get 
the final 1.0 spec. out there and have feedback based on that before we 
decide to add or remove anything.

Mark.

>- - JohnK
>
>  
>
>>Gudge 
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: public-ws-addressing-request@w3.org 
>>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of 
>>>Conor P. Cahill
>>>Sent: 16 October 2005 18:39
>>>To: Rogers, Tony
>>>Cc: David Orchard; John Kemp; ext Mark Little; Mark 
>>>Nottingham; WS-Addressing
>>>Subject: RE: Multiple Addresses in an EPR
>>>
>>>
>>>
>>>
>>>Rogers, Tony wrote on 10/16/2005, 9:02 PM:
>>>
>>>      
>>>
>>>>So I would prefer that those who have this newly 
>>>>        
>>>>
>>>discovered need can
>>>      
>>>
>>>>choose to solve it in one of the other ways that you have outlined,
>>>>rather than hold back a standard that is in CR phase already - yes.
>>>>Making the change that you propose would drag the spec 
>>>>        
>>>>
>>>back to LC again,
>>>      
>>>
>>>>and delay it for everyone.
>>>>        
>>>>
>>>That's what the CR process is about.  If one can't raise issues
>>>and get them resolved, then there doesn't need to be a CR phase
>>>at all.
>>>
>>>On a technical basis, I haven't heard anyone say that this isn't
>>>a resonable use case.
>>>
>>>      
>>>
>>>>Your fear that there will be a variety of implementations may be
>>>>groundless - if you choose one and describe it now, then others can
>>>>follow your lead, and all will be well.
>>>>        
>>>>
>>>So you're telling me that CA and other implementors will commit to
>>>adopt one that I choose to describe now?   I'm guessing not.  I'm
>>>guessing that there will be many toolkits that either a) don't
>>>support this functionality at all because it isn't in the spec,
>>>or b) choose to do it in a different non-interoperable way.
>>>
>>>      
>>>
>>>>"Not having this capability makes it very hard/inefficient 
>>>>        
>>>>
>>>to support a
>>>      
>>>
>>>>real world use of the spec."
>>>>
>>>>Not true - you have described multiple ways in which you might
>>>>implement a solution, and they appear both simple and efficient
>>>>(perhaps not as aesthetically pleasing). If there were truly no
>>>>way in which the problem might be addressed, other than changing
>>>>the spec, then I would be more sympathetic.
>>>>        
>>>>
>>>A) My comment was more related to trying to follow the spec as
>>>written since that is all that out-of-the-box toolkits will
>>>be able to do).  The spec currently requires that the physical
>>>address be carried in a single wsa:Address element.  So if I
>>>wanted to follow the spec and I had multiple addresses I would
>>>have to have multiple EPRs (othewise I risk that clients
>>>built off the spec will not recognize the alternative addresses).
>>>
>>>B) Given that a spec has an xs:any in the EPR, I could put the
>>>kitchen sink in there, so there's pretty much no problem that
>>>would be impossible to resolve.  That doesn't mean that there
>>>aren't good reasons to have defined elements (which is why,
>>>even though there is an xs:any, the spec does define Address,
>>>ReferenceParameters, and Metadata).
>>>
>>>Conor
>>>
>>>
>>>
>>>
>>>      
>>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (Darwin)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDUw1BmNJiOOM57NMRAtthAJwJzvs/eQtyMSodYniL8mmqXc0AagCdFRKV
>agwwkP3fOHPnCTiyeU2lCIs=
>=e6VC
>-----END PGP SIGNATURE-----
>
>  
>

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
www.arjuna.com

Received on Monday, 17 October 2005 09:36:49 UTC