- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Tue, 3 Apr 2007 12:10:23 -0700
- To: "David Illsley" <david.illsley@uk.ibm.com>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>
- CC: WS-Addressing <public-ws-addressing@w3.org>, "public-ws-addressing-request@w3.org" <public-ws-addressing-request@w3.org>, "tom@coastin.com" <tom@coastin.com>
It depends on whether nested assertions are considered part of the "policy vocabulary". Like you, I assumed they were and thus, your interpretation is correct, but, to be sure, I sent mail to the Policy WG to confirm. We should get a reply soon.
All the best, Ashok
> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-
> request@w3.org] On Behalf Of David Illsley
> Sent: Tuesday, April 03, 2007 11:05 AM
> To: Anish Karmarkar
> Cc: WS-Addressing; public-ws-addressing-request@w3.org; tom@coastin.com
> Subject: Re: Consolodated changes for alterngive G prime
>
>
> 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 19:12:20 UTC