- From: David Illsley <david.illsley@uk.ibm.com>
- Date: Tue, 3 Apr 2007 19:04:37 +0100
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: WS-Addressing <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org, tom@coastin.com
Hi Anish,
Unfortunately, in speaking to one of our policy experts, there seems to be
a negation concern with at least one scenario - the one in the example in
fact... consider the following
What is the meaning of Alternative 1 in this situation?
Example 3-8. Client looking for an endpoint which supports Addressing, and
does not require support for responses (will intersect with anything)
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing> <-- supports all response types -->
Alternative 1
<wsp:Policy>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
<wsp:All>
<wsam:Addressing> <-- requires Anonymous responses -->
Alternative 2
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<AnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
<wsp:All>
<wsam:Addressing> <- requires nonAnonymous responses -->
Alternative 3
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<NonAnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
My reading (of Framework, 3.2) is that because the AnonymousResponses
assertion is found in Alternative 2 that the negation rule means that
Alternative 1 includes a 'must not do AnonymousResponses meaning'. And
similarly that because of Alternative 3, Alternative 1 includes a 'must
not do NonAnonymousResponses meaning'. If so, Alternative 1 (in this
context) does not mean "supports all response types", but in fact
"Addressing is supported but you must not send Anonymous or Non-Anonymous
response EPRs".
Do you agree with this interpretation?
David
David Illsley
Web Services Development
MP211, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com
public-ws-addressing-request@w3.org wrote on 04/03/2007 12:30:50 AM:
>
> On the negation of nested assertion issue that we talked about today on
> the call. I asked our internal policy expert (aka Ashok) about this and
> his explanation was that the proposal as it is written, wrt the negation
> issue, is fine. I.e., we can say (as we have) that absence of either of
> the nested assertion means support for both (or that no claim is made).
>
> Negation applies *only* when there are two (or more) alternatives: P and
> Q. P contains an assertion A (either top-level or nested) and Q does
> not. If one chooses alternative Q, then that is equivalent to negation
of A.
>
> HTH.
>
> -Anish
> --
>
> Tom Rutt wrote:
> > attached is html showing all changes agreed today
> >
> > MarcG alternative G proposal:
> >
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0043.html
> >
> > as amended by Tom Rutt Email
> >
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0053.html
> >
> >
> >
------------------------------------------------------------------------
> >
> >
> > 3. Indicating Use of WS-Addressing
> >
> > This specification supports a mechanism for indicating, in a WSDL
> > description, that the endpoint conforms to the WS-Addressing
> > specification. That mechanism uses WS-Policy Framework [WS Policy 1.5
-
> > Framework <#WSPolicy>].
> >
> >
> > 3.1 WS-Policy Assertions
> >
> > The mechanism for indicating that a binding or endpoint conforms to
the
> > WS-Addressing specification is through the use of the Web Services
> > Policy - Framework [WS Policy 1.5 - Framework <#WSPolicy>] and Web
> > Services Policy - Attachment [WS Policy 1.5 - Attachment
> > <#WSPolicyAttachment>] specifications. This specification defines
three
> > policy assertions.
> >
> > The wsam:Addressing policy assertion applies to the endpoint policy
subject.
> >
> > For WSDL 1.1, these assertions may be attached to |wsdl11:port| or
> > |wsdl11:binding|. For WSDL 2.0, they may be attached to
> > |wsdl20:endpoint| or |wsdl20:binding|.
> >
> > A policy expression containing the wsam:Addressing policy assertion
MUST
> > NOT be attached to a wsdl:portType or wsdl20:interface. The
> > wsam:Addressing policy assertion specifies a concrete behavior whereas
> > the wsdl:portType or wsdl20:interface is an abstract construct.
> >
> >
> > 3.1.1 Addressing Assertion
> >
> > The wsam:Addressing policy assertion is a nested policy container
> > assertion. The meaning of this assertion, when present in a policy
> > alternative, is that WS-Addressing is required to communicate with the
> > subject. The wsam:Addressing assertion indicates that there are no
> > restrictions on the use of WS-Addressing unless otherwise qualified by
> > assertions in its nested policy expression. In order to indicate that
> > the subject supports WS-Addressing but does not require its use, an
> > additional policy alternative should be provided which does not
contain
> > this assertion. This may be done in WS-Policy compact form by adding
the
> > attribute wsp:Optional="true" to the wsam:Addressing assertion.
> >
> >
> >
> >
> > 3.1.2 AnonymousResponses Assertion
> >
> > The wsam:AnonymousResponses element MAY be used as a policy assertion
> > nested within the wsam:Addressing assertion in accordance with the
rules
> > laid down by WS-Policy Framework 1.5 section 4.3.2.
> >
> > The appearance of this element within a policy alternativethe
> > wsam:Addressing policy assertion indicates that the endpoint expresses
> > explicitrequires support for request messages with to use response
> > endpoint EPRs that contain the anonymous URI
> > ("http://www.w3.org/2005/08/addressing/anonymous") as the value of
> > [address]. In other words, the endpoint guarantees support forrequires
> > the use of anonymous responses.
> >
> > The absence of the wsam:AnonymousResponses policy assertion within a
> > policy alternative does *not* indicate that the endpoint will not
accept
> > request messages with response endpoint EPRs that contain the
anonymous
> > URI as an address; it simply indicates the lack of any affirmation of
> > support for anonymous URIs.
> >
> > The None URI ("http://www.w3.org/2005/08/addressing/none") may appear
as
> > the value of [address] in place of the anonymous URI; this value MUST
be
> > accepted.
> >
> >
> > 3.1.3 NonAnonymousResponses Assertion
> >
> > The wsam:NonAnonymousResponses element MAY be used as a policy
assertion
> > nested within the Addressing assertion in accordance with the rules
laid
> > down by WS-Policy Framework 1.5 section 4.3.2. The
> > wsam:NonAnonymousResponses policy assertion MUST NOT be used in the
same
> > policy alternative as the wsam:AnonymousResponses policy assertion.
> >
> > The appearance of this element within a policy alternativethe
> > wsam:Addressing assertion indicates that the endpoint expresses
explicit
> > support forrequires request messages with to use response endpoint
EPRs
> > that contain something other than the anonymous URI as the value of
> > [address]. In other words, the endpoint guarantees support forrequires
> > the use of non-anonymous responses. This assertion is deliberately
> > vague; its presence indicates that some non-anonymous addresses will
be
> > accepted but doesn't constrain what such an address might look like. A
> > receiver can still reject a request that contains an address that it
> > doesn't understand or that requires a binding it doesn't support.
> >
> > As with the other assertions, the absence of the
> > wsam:NonAnonymousResponses policy assertion within a policy
alternative
> > does *not* indicate that the endpoint will not accept request messages
> > with response endpoint EPRs that contain something other than the
> > anonymous URI address; it simply indicates the lack of any affirmation
> > of support for them.
> >
> > The None URI ("http://www.w3.org/2005/08/addressing/none") may appear
as
> > the value of [address] in place of a non-anonymous address; this value
> > MUST be accepted.
> >
> >
> > 3.1.4 Examples (Compact Form)
> >
> > /Example 3-1.// Subject supports WS-Addressing, no statement on
> > supported response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsam:Addressing wsp:Optional="true">
> >
> > <wsp:Policy/>
> >
> > </wsam:Addressing>
> >
> > </wsp:Policy>
> >
> > /Example 3-2.// Subject requires WS-Addressing, no statement on
> > supported response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy/>
> >
> > </wsam:Addressing>
> >
> > </wsp:Policy>
> >
> > /Example 3-3. Subject supports WS-Addressing, explicitly (and
> > optionally) supports anonymous and non-anonymous response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsam:Addressing wsp:Optional="true">
> >
> > <wsp:Policy>
> >
> > <wsam:AnonymousResponses wsp:Optional="true"/>
> >
> > <wsam:NonAnonymousResponses wsp:Optional="true"/>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:Policy>
> >
> > /Example 3-4. Subject requires WS-Addressing, requires explicit
support
> > of anonymous or non-anonymous response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsam:AnonymousResponses/>
> >
> > <wsam:NonAnonymousResponses/>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:Policy>
> >
> > /Example 3-53.// Subject requires WS-Addressing and explicit
> > supportrequires the use of non-anonymous response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsam:NonAnonymousResponses/>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:Policy>
> >
> >
> > 3.1.5 Examples (Normal Form)
> >
> > /Example 3-46. Subject supports WS-Addressing, no statement on
supported
> > response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All/>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All/>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > /Example 3-57. Subject requires WS-Addressing, no statement on
supported
> > response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All/>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > /Example 3-8. Subject supports WS-Addressing, explicitly (and
> > optionally) supports anonymous and non-anonymous response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All/>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All/>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:AnonymousResponses/>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:NonAnonymousResponses/>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:AnonymousResponses/>
> >
> > <wsam:NonAnonymousResponses/>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > /Example 3-9. Subject requires WS-Addressing, requires explicit
support
> > of anonymous or non-anonymous response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:AnonymousResponses/>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:NonAnonymousResponses/>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > /Example 3-610. Subject requires WS-Addressing and explicit support
> > ofrequires the use of non-anonymous response EPRs/
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:NonAnonymousResponses/>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> >
> > 3.1.6 Finding Compatible Policies
> >
> >
> > When a client is looking for an endpoint with compatible
policy,
> > one common method used is to take the policy intersection
> > between the policy which the client is looking for, and the
> > policy asserted in the WSDL document; a non-empty intersection
> > is sought. The policy used by the client must be written
> > carefully to avoid unexpected results. This is most obvious
when
> > the client is not looking for explicit support of a particular
> > kind of response; failing to take care could mean missing a
> > compatible policy.
> >
> > /Example 3-7. Client looking for an endpoint which supports
Addressing,
> > and which supports anonymous responses/
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:Addressing>
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <AnonymousResponses Optional=?true? />
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > /Example 3-8. Client looking for an endpoint which supports
Addressing,
> > and does not require support for responses (will intersect with
anything)/
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <wsam:Addressing> <-- supports all response types -->
> >
> > <wsp:Policy>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > <wsp:All>
> >
> > <wsam:Addressing> <-- requires Anonymous responses -->
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <AnonymousResponses />
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > <wsp:All>
> >
> > <wsam:Addressing> <- requires nonAnonymous responses -->
> >
> > <wsp:Policy>
> >
> > <wsp:ExactlyOne>
> >
> > <wsp:All>
> >
> > <NonAnonymousResponses />
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> > </wsam:Addressing>
> >
> > </wsp:All>
> >
> > </wsp:ExactlyOne>
> >
> > </wsp:Policy>
> >
> >
> >
> >
> >
> >
> >
> >
> > For more detailed descriptions of the use of wsp:Optional,
> > wsp:Ignorable, and strict and lax intersection, please refer
to
> > the WS-Policy Primer [WS Policy 1.5 - Primer
<#WSPolicyPrimer>].
> >
> >
> >
> >
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Received on Tuesday, 3 April 2007 18:04:56 UTC