- From: John Kemp <john.kemp@nokia.com>
- Date: Sun, 16 Oct 2005 22:32:33 -0400
- To: ext Martin Gudgin <mgudgin@microsoft.com>
- CC: "Conor P. Cahill" <concahill@aol.com>, "Rogers, Tony" <Tony.Rogers@ca.com>, David Orchard <dorchard@bea.com>, ext Mark Little <mark.little@arjuna.com>, Mark Nottingham <markn@bea.com>, WS-Addressing <public-ws-addressing@w3.org>
-----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. - - 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-----
Received on Monday, 17 October 2005 02:33:20 UTC