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