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

Anish,

Your "supported" language seems to bring us right back to the LC issue
raised by the WS-Policy WG:
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0006.html.

- gp 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Anish Karmarkar
> Sent: Monday, April 16, 2007 11:44 AM
> To: tom@coastin.com
> Cc: WS-Addressing; ws policy
> Subject: Re: New Proposed Alternative H to resolve WS Policy 
> LC comments on WSAM
> 
> 
> 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
> > 
> 
> 
>