W3C home > Mailing lists > Public > public-ws-addressing@w3.org > May 2009

Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 19 May 2009 15:20:17 -0400 (EDT)
To: Gilbert Pilz <gilbert.pilz@oracle.com>
cc: Bob Freund <Bob.Freund@hitachisoftware.com>, David Illsley <david.illsley@uk.ibm.com>, Anish Karmarkar <Anish.Karmarkar@oracle.com>, ashok.malhotra@oracle.com, Fabian Ritzmann <Fabian.Ritzmann@Sun.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
Message-ID: <alpine.DEB.1.10.0905191517280.25717@wnl.j3.bet>
On Tue, 19 May 2009, Gilbert Pilz wrote:

> I'm not sure what this has to do with our proposal since we aren't 
> "contradicting" anything. We're adding an optional attachment point for 
> policies containing the wsam:Addressing assertion. The semantics of 
> wsam:Addressing, wsam:Anonymous, and wsam:NonAnonymous are not being changed.

Let's say that in HTML we allow <head> after <body> in the specification 
"PigFarmML", isn't that a problem for all existing HTML parsing 
implementations? Most probably yes (well ok, the choice of HTML might not 
be the best here). So the semantic of the qnames is one thing, but where 
to put them is also part of interop and the specification itself.

> - gp
> On 5/19/2009 10:19 AM, Yves Lafon wrote:
>> 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.

Received on Tuesday, 19 May 2009 19:20:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:17 UTC