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: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Tue, 19 May 2009 11:10:39 -0700
Message-ID: <4A12F61F.2090301@oracle.com>
To: Yves Lafon <ylafon@w3.org>
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
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 

- 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).

Received on Tuesday, 19 May 2009 18:12:41 UTC

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