RE: Multiple Addresses in an EPR

I thought the CR phase was about figuring out whether the spec could be
implemented 'as written'...

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
> 
> 
> 
>

Received on Monday, 17 October 2005 02:18:48 UTC