- 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