W3C home > Mailing lists > Public > public-ws-addressing@w3.org > October 2005

RE: Multiple Addresses in an EPR

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Sun, 16 Oct 2005 19:18:40 -0700
Message-ID: <DD35CC66F54D8248B6E04232892B6338074400AF@RED-MSG-43.redmond.corp.microsoft.com>
To: "Conor P. Cahill" <concahill@aol.com>, "Rogers, Tony" <Tony.Rogers@ca.com>
Cc: "David Orchard" <dorchard@bea.com>, "John Kemp" <john.kemp@nokia.com>, "ext Mark Little" <mark.little@arjuna.com>, "Mark Nottingham" <markn@bea.com>, "WS-Addressing" <public-ws-addressing@w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:09 GMT