- From: Tom Rutt <tom@coastin.com>
- Date: Tue, 03 Apr 2007 17:01:06 -0400
- To: David Illsley <david.illsley@uk.ibm.com>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, WS-Addressing <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
Negation is never mentioned in either alternative G or F.
The idea for alternative G is unqualified "addressing" assertion means
adressing supported, while the nested policy assertions are
expressing application restrictions (i.e., anon only or non anon only).
Alternative F states that empty implies no response eprs other than NONE
may be used. This is closer to negation, but still does not use the word
:negation or negatory or whatever.
Tom
We are hoping to define this without discussion negation whatsoever.
Tom
David Illsley wrote:
> 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
>
>
>
>
>
>
>
>
--
----------------------------------------------------
Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Tuesday, 3 April 2007 21:01:17 UTC