W3C home > Mailing lists > Public > public-ws-addressing@w3.org > April 2007

Re: New Proposed Alternative H to resolve WS Policy LC comments on WSAM

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 16 Apr 2007 11:43:38 -0700
Message-ID: <4623C3DA.8030300@oracle.com>
To: tom@coastin.com
CC: WS-Addressing <public-ws-addressing@w3.org>, ws policy <public-ws-policy@w3.org>

Tom,

Why not define just two nested assertions and allow then to be specified 
together. I.e., do the following:

wsam:Addressing -- says that it supports ws-addressing spec (nothing 
more, nothing less). On its own does not say anything about anon or 
non-anon, they may be supported, YMMV.

nested assertion wsam:AnonymousResponse -- says that anonymous response 
is supported.

nested assertion wsam:NonAnonymousResponse -- says that the non-anon 
response is supported.

This is how various usecases would look like.

1) usecase 1: ws-addressing is supported (nothing more)

[apologies for errors in ws-policy syntax, if any]

<wsp:Policy>
   <wsp:ExactlyOne>
     <wsp:All>
        <wsam:Addressing/>
     </wsp:All>
   </wsp:ExactlyOne>
<wsp:Policy>

2) usecase 2: WS-addressing with guarantee that anon is supported:

<wsp:Policy>
   <wsp:ExactlyOne>
     <wsp:All>
       <wsam:Addressing>
         <wsp:Policy>
           <wsp:ExactlyOne>
             <wsp:All>
               <wsam:AnonymousResponse/>
             </wsp:All>
           </wsp:ExactlyOne>
       </wsam:Addressing>
     </wsp:All>
   </wsp:ExactlyOne>
<wsp:Policy>

3) usecase 3: ws-addressing with guarantee that non-anon is supported:

<wsp:Policy>
   <wsp:ExactlyOne>
     <wsp:All>
       <wsam:Addressing>
         <wsp:Policy>
           <wsp:ExactlyOne>
             <wsp:All>
               <wsam:NonAnonymousResponse/>
             </wsp:All>
           </wsp:ExactlyOne>
       </wsam:Addressing>
     </wsp:All>
   </wsp:ExactlyOne>
<wsp:Policy>

4) usecase 4: ws-addressing with guaranted that both anon and non-anon 
are supported:

<wsp:Policy>
   <wsp:ExactlyOne>
     <wsp:All>
       <wsam:Addressing>
         <wsp:Policy>
           <wsp:ExactlyOne>
             <wsp:All>
               <wsam:AnonymousResponse/>
             </wsp:All>
             <wsp:All>
               <wsam:NonAnonymousRespone/>
             <wsp:All>
           </wsp:ExactlyOne>
       </wsam:Addressing>
     </wsp:All>
   </wsp:ExactlyOne>
<wsp:Policy>

WRT policy matching,
1) if one were looking for ws-addressing with a guarantee that (say) 
anonymous was supported, one would look for a policy similar to one in 
usecase 2.

2) if one were looking for ws-addressing with possible anon support (but 
no guarantee), then one would look for a match for { usecase 1 OR 
usecase 2}.

-Anish
--

Tom Rutt wrote:
> It seems there is quite a bit of discussion on the meaning of an empty 
> assertion, when that assertion is defined to allow nested
> assertion types.
> 
> One way for wsa to totally avoid this interpretation question is to 
> define the Addressing assertion in such a way that one
> and only one of the following three nested assertions MUST be present in 
> any alternative using the Addressing assertions:
> OnlyAnonymousResponses.
> OnlyNonAnonymousResponses
> BothResponseTypes
> 
> to indicate any restrictions on response EPR types.
> 
> I attach this new proposal for discussion :
> 
> Tom Rutt
> 
Received on Monday, 16 April 2007 18:45:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:17 GMT