- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Wed, 22 Feb 2006 14:05:27 -0500
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
- Cc: dmh@tibco.com, "David Orchard" <dorchard@bea.com>, paul.downey@bt.com, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
- Message-ID: <OF614B1E22.ECD41F5F-ON8525711D.00688A0C-8525711D.0068DD5D@us.ibm.com>
+1! Christopher Ferris STSM, Emerging e-business Industry Architecture email: chrisfer@us.ibm.com blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440 phone: +1 508 377 9295 public-ws-addressing-request@w3.org wrote on 02/22/2006 01:34:13 PM: > > It seems to me we are just making a big deal out of an issue which is > easily fixed here in WS-A. > > We separate the problem into two separate issues: > > --define the anonymous URI's semantics > --define the WS-A MAP semantics for reply endpoint/fault endpoint with > anonymous value. This wg can provide specific semantics for these two > MAPs we define which builds on anonymous URI and their relationship to > MEPs. > > Nothing more, nothing less. > > Katy's proposal for CR23 [1] is definitely in the right direction and we > should fix this problem in this manner, by careful decomposition of the > problem. > > Intermixing the solution of these two issues and thinking in a very > restricted sense for the semantics of anonymous is not a good approach. > As a matter of fact, fusing the two solutions breaks composition for > other groups. The semantics of Anonymous should not be restricted to > specific MEPs, but can be further used to define the semantics in > certain MEPs and WS-A MAPs. Fusing the two prevents the composition, IMO > and I am weary of the tendency here. > > WS-RX can define the semantics of acksTo (which it owns) based on the > anonymous URI only. It can crisply define how acksTo can be used in its > own context and in conjunction with its own protocol exchanges/when it > is allowed, etc. > > It seems to me that resolving CR23 in this manner, we do not hinder any > composition, not the other way around. > > --umit > > > [1] > http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0167.ht > ml > > > -----Original Message----- > > From: public-ws-addressing-request@w3.org > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > > David Orchard > > Sent: Wednesday, Feb 22, 2006 8:27 AM > > To: paul.downey@bt.com; dmh@tibco.com; public-ws-addressing@w3.org > > Subject: RE: Clarification for WS-RX > > > > > > OTOH, the last thing I want is some profile to crop up that > > "fixes" for > > WS-RX how "broken" WS-A is. At the end of the day, the stuff is > > supposed to be composable, etc. > > > > Cheers, > > Dave > > > > > -----Original Message----- > > > From: public-ws-addressing-request@w3.org > > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > > > paul.downey@bt.com > > > Sent: Wednesday, February 22, 2006 6:09 AM > > > To: dmh@tibco.com; public-ws-addressing@w3.org > > > Subject: RE: Clarification for WS-RX > > > > > > > > > > > > > > > > I'm a bit loath to send this to the whole WS-RX list, and I think > > > > there are enough WS-RXperts here to answer, so ... > > > > > > but this is Web service addressing and I'm bothered that we > > > do seem to keep descending into glorious detail on how WS-RX > > > may or may not work, rather than answering tractable LC and > > > CR comments from that WG wrt our specifications. > > > > > > Paul > > > > > > > > ______________________________________________________________ > > _________ > > Notice: This email message, together with any attachments, > > may contain > > information of BEA Systems, Inc., its subsidiaries and > > affiliated > > entities, that may be confidential, proprietary, > > copyrighted and/or > > legally privileged, and is intended solely for the use of the > > individual > > or entity named in this message. If you are not the intended > > recipient, > > and have received this message in error, please immediately > > return this > > by email and then delete it. > > > > >
Received on Wednesday, 22 February 2006 19:06:37 UTC