RE: Consolodated changes for alterngive G prime

I think we need to enumerate all the WS-Addressing usecases and try and write policies for them.

Anish and I came up with five usecases:

 

1.	Use WS-Addressing
2.	Use WS-Addressing with anonymous for all responses
3.	Use WS-Addressing with non-anonymous for all responses
4.	Use WS-Addressing with both anon and non-anon being allowed for all responses
5.	Do not use WS-Addressing

 

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.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
>
>
>
>

-- 
----------------------------------------------------
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 14:49:26 UTC