- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 19 May 2009 13:19:09 -0400 (EDT)
- To: Bob Freund <Bob.Freund@hitachisoftware.com>
- cc: David Illsley <david.illsley@uk.ibm.com>, Anish Karmarkar <Anish.Karmarkar@oracle.com>, ashok.malhotra@oracle.com, Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>, Gilbert Pilz <gilbert.pilz@oracle.com>, Jitendra.Kotamraju@Sun.COM, Monica Martin <momartin@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, Rama Pulavarthi <Rama.Pulavarthi@Sun.COM>, Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>, "Rogers, Tony" <Tony.Rogers@ca.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, wsi_wsbasic@mp.ws-i.org
On Mon, 23 Feb 2009, Bob Freund wrote:
> 1) My understanding is that the goal of WS-I and its profiles, are in general
> to improve interoperability of the Web Services Stack.
> The proposals do not improve interoperability since they introduce a feature
> that is not contained in strictly implemented and conformant versions of
> WS-Addressing. To the contrary, they introduce new functionality that
> current conformant implementations do not have and thus create
> incompatibilities with existing implementations. The goal of improving
> interoperability is violated. Perhaps future implementations that had this
> new feature might become interoperable, but until that time, correct
> implementations would not interoperate with "new-style" implementations.
I won't comment on the goals of WS-I, but having a new specification
contradicting an older one is a good source of interop issues, and I would
recommend to find another way to do this.
> 3) Should the community desire this feature enough to seriously endeavor to
> make it happen, then it ought to deal with it as an amendment or next
> revision to the WS-Addressing specification. Simply because it is rather
> unlikely, albeit possible, to charter a group within the W3C, it seems that
> the level of difficulty in some way appropriately reflects the community
> at-large and its opinion about the necessity of this proposal. Adding this
> feature by virtue of the smaller circle of debate within the WS-I BP WG of
> the WS-I does not bode well for its acceptance and thus the acceptance of
> profiles in which this requirement might be contained.
Nothing is impossible, even creating new WGs in W3C's Web Services
activity is possible if backed by enough companies and with a clear
roadmap.
>> It is my assertion that the BP use cases could be satisfied by:
>> 1. Allowing WS-A assertions to be attached to the binding operation if and
>> only if no WS-Addressing assertions are attached at the endpoint subject
>> 2. WS-A assertions must be present either on all binding operations of a
>> given binding or none of them.
Why not creating a new element that can be attached where you want and
"should be interpreted as WSAM" (even if is dangerous if ever WSAM
change) ?
I don't understand why doing a non-interoperable change to the way WSAM
is/can be implemented based only on WSAM is helping here. Having the
functionnality being split between two specs with no links between them is
just not workable.
Also extending something in a namespace not owned by the group defining it
is at best bad practise, and at worst will open the room of interpretation
of copyright laws on that matter (as the new spec in question would be
putting words in somone else's mouth without its consent).
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Tuesday, 19 May 2009 17:19:27 UTC