- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Mon, 02 Apr 2007 16:30:50 -0700
- To: tom@coastin.com
- CC: WS-Addressing <public-ws-addressing@w3.org>
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>].
>
>
>
>
Received on Monday, 2 April 2007 23:32:46 UTC