- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Mon, 16 Apr 2007 11:43:38 -0700
- 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 UTC