- From: David Orchard <dorchard@bea.com>
- Date: Wed, 4 Apr 2007 09:20:57 -0700
- To: "Ashok Malhotra" <ashok.malhotra@oracle.com>, "Maryann Hondo" <mhondo@us.ibm.com>, <tom@coastin.com>
- Cc: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "David Illsley" <david.illsley@uk.ibm.com>, "WS-Addressing" <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
- Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C037EEB1B@repbex01.amer.bea.com>
Anything for V.Next of Policy on how to write those?
Dave
The usecase of using anon for some responses (say replyTo) and
non-anon for others (say fault) was, I believe, rejected by the WG.
That's good, because it involves message level policies in conjunction
with endpoint policies and I don't see how to write that :-)
All the best, Ashok
________________________________
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Maryann Hondo
Sent: Wednesday, April 04, 2007 7:30 AM
To: tom@coastin.com
Cc: Anish Karmarkar; David Illsley; WS-Addressing;
public-ws-addressing-request@w3.org
Subject: Re: Consolodated changes for alterngive G prime
Tom,
I meant two different policy expressions.
I apologize if I have introduced any confusion, I have as we
say in Boston, a "wicked" head cold :-)
My point was just that supporting all response types seems to
cover all "alternatives". Rather than starting up more threads here,
I think what will be most productive is for the ws-policy group
to review what the ws-addressing group has sent
and then for the ws-policy group to reply....wow a message
exchange pattern :-)
I've been trying to follow all the mail, but perhaps I have
missed some of the exchanges.
Since you're in both groups, perhaps we can discuss this on the
call today.
Maryann
Tom Rutt <tom@coastin.com>
Sent by: public-ws-addressing-request@w3.org
04/03/2007 06:56 PM
Please respond to
tom@coastin.com
To
Maryann Hondo/Austin/IBM@IBMUS
cc
Anish Karmarkar <Anish.Karmarkar@oracle.com>, David Illsley
<david.illsley@uk.ibm.com>, WS-Addressing <public-ws-addressing@w3.org>,
public-ws-addressing-request@w3.org
Subject
Re: Consolodated changes for alterngive G prime
I am not sure what it means to have two different endpoint
policies.
How is this different than one policy with three alternatives?
Tom
Maryann Hondo wrote:
>
> Tom,
>
> In my opinion, negation is part of the policy framework when
there are
> alternatives within a policy vocabulary, which is what you
currently
> have in your example. I think you will need 2 different
endpoint
> policies to support the variations you want.
>
> endpoint 1
> <wsp:Policy>
> <wsp:All>
> <wsam:Addressing> <-- supports all response types
-->
> </wsp:All>
> </wsp:Policy>
>
> endpoint 2
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All>
> <wsam:Addressing> <-- requires Anonymous responses
-->
> Alternative 1
> <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 2
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All>
> <NonAnonymousResponses />
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> Maryann
>
>
> *Tom Rutt <tom@coastin.com>*
> Sent by: public-ws-addressing-request@w3.org
>
> 04/03/2007 05:01 PM
> Please respond to
> tom@coastin.com
>
>
>
> 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
> Subject
> Re: Consolodated changes for alterngive G
prime
>
>
>
>
>
>
>
>
>
>
> 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.ht
ml
> >
> >>> as amended by Tom Rutt Email
> >>>
> >>>
> >
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0053.ht
ml
> >
> >>>
> >>>
> >
------------------------------------------------------------------------
> >
> >>> 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
>
>
>
>
--
----------------------------------------------------
Tom Rutt email: tom@coastin.com;
trutt@us.fujitsu.com
Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Wednesday, 4 April 2007 16:40:35 UTC