RE: First cut policy write up

I continue to be fascinated with this thread.

> As I recall, we decided that "UsingAddressing" always has one meaning 
> is that WS-Addr is "supported".

If this is the case, and that when in conjunction with 
wsdl:required='true' that it effectively changes the
semantic to that of the 11th commandment: "Thou shalt use WS-Addressing", 
then I guess I am confused,
because wsa:UsingAddressing no longer has the semantic of "WS-Addressing 
is supported" except implicitly.
(If the endpoint is admonishing its prospective consumers that they MUST 
use WS-Addressing, lest they
suffer the Wrath of Khan, or the WS-Overlords, or whomever dishes out 
wrath in the context of WS-*dom,
then that admonishment obviously implies that WS-Addressing is supported 
at that endpoint, or else they would not
have written that commandment into their WSDL tablet in the first place.)
The semantic of wsdl:required='true' is that it means that the consumer of 
understand that EXTENSION in order that they be able to effectively use 
the WSDL description [1]. WSDL2.0
basically has the same semanic. wsdl20:required='true' effectively means 
that the extension may change the
semantic of the parent WSDL element in a manner in which if not 
understood, would prevent the client
from correctly interacting with the endpoint described.

So, in both cases, what the semantic of wsdl:required='true' adds to a 
given extension is that you MUST
understand that extension's semantic. If wsa:UsingAddressing means 
"WS-Addressing is supported", then
the mere presence of wsdl:required='true' cannot change that semantic into 
"Thou shalt use WS-Addressing".
wsa:UsingAddressing still means "WS-Addressing is supported".

If you want to convey a requirement that WS-Addressing MUST be used, then 
you need an extension that
says that,unambiguously in its semantic, absent the presenceor absenceof 

If you want the semantic that WS-Addressing is supported, but not required 
(e.g. optional) then use wsdl:required='false'
(the default in both cases IIRC) as a means of providing the consumer of 
the WSDL to choose whether they
want to "understand" the semantic of the wsa:UsingAddressing WSDL 
extension (of course, I would strongly
suggest renaming the extension to something a little more descriptive of 
the semantic carried: e.g. wsa:UseAddressing).

If the semantic of the extension means: "Thou shalt use WS-Addressing", 
then clearly, it can be used in WS-Policy
with the wsp:Optional='true' to indicate that there are two policy 
alternatives available to the consumer: one with,
and one without the admonition that "Thou shalt use WS-Addressing".

IMO, wsa:UsingAddressing is broken if its current semantic is 
"WS-Addressing supported" because you
can't change its semantic with wsdl:required='true'since 
wsdl:required='true' isn't intended to CHANGE the semantic
of the extension, but merely to signal to the WSDL processor that it MUST 
understand the extension's semantic.



Christopher Ferris
STSM, Software Group Standards Strategy
phone: +1 508 377 9295 wrote on 12/04/2006 02:15:07 PM:

> David's understanding of the semantics of the wsaw:UsingAddressing 
> assertion is in line with my intentions in describing it and (I hope) in
> line with what the group decided on the 11/27 concall.
> As I recall, we decided that "UsingAddressing" always has one meaning 
> is that WS-Addr is "supported". When used as a WSDL extension in 
> with 'wsdl:required="true"' it means that WS-Addr is required. 
> there doesn't seem to be a way of both keeping the semantics of
> "UsingAddressing" constant across its use as a WSDL extension and a 
> assertion *and* allowing the WS-Policy variation to express that the use 
> WS-Addr is required. I thought we had discussed this and agreed that we
> would have to live with it. If you really need to express the fact that
> WS-Addr is required for an endpoint you will have to use
> wsaw:UsingAddressing as a WSDL extension and mark it with
> 'wsdl:required="true"'.
> As for nested policy assertions, again, I thought we had discussed this 
> decided that they were too complicated. I now think we were a bit 
> in that decision and I agree that nested policy assertions work best for
> expressing the relationship between the broad "UsingAddressing" 
> and the narrower "AnonymousReponses" and "NonAnonymousResponse".
> - gp
> "too forward and one back
>  blind fingers groping for the right track"
> > -----Original Message-----
> > From: David Illsley [] 
> > Sent: Monday, December 04, 2006 4:40 AM
> > To: Yalcinalp, Umit
> > Cc: Gilbert Pilz;
> > Subject: RE: First cut policy write up
> > 
> > Comments below.
> > 
> > wrote on 12/01/2006 10:34:05 PM:
> > 
> > > > I spent a while yesterday going over this proposal with 
> > Katy, Paco, 
> > > > and our WS-Policy development team and we have a couple 
> > of concerns.
> > > > 
> > > > 1. There is no way to mandate addressing in this proposal i.e. In 
> > > > normal form (once the wsp:Optionals etc have been expanded) the 
> > > > presence of wsaw:UsingAddressing only indicates addressing is 
> > > > supported.
> > > > We need a way
> > > > to say addressing is required. I don't have a proposal 
> > yet to deal 
> > > > with this.
> > > > 
> > > 
> > > I am really not following this point. Could you clarify? 
> > > 
> > > If you do not use wsp:optional and use the standard attachment 
> > > mechanisms, why wouldn't WS-Addressing be NOT required.
> > > 
> > > IF there is no alternative in the policy, the intersection 
> > algorithm 
> > > and thus the client will treat WS-Addressing assertion as 
> > an addition 
> > > that it needs to understood and thus make behavior required.
> > > 
> > 
> > I agree that in those circumstances, the UsingAddressing 
> > assertion would be required for the client.
> > However, the example states:
> > > > <wsp:Policy>
> > > >   <wsaw:UsingAddressing>
> > > > </wsp:Policy>
> > > > This policy indicates that the subject supports the use of
> > WS-Addressing. 
> > 
> > It explicitly does not say that inclusion of UsingAddressing in an 
> > alternative mandates the use of WS-Addressing, merely that it is 
> > supported, hence the concern.
> > 
> > David
> > 

Received on Monday, 4 December 2006 20:25:23 UTC