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

Good point.
s/supported/required/

-Anish
--

Gilbert Pilz wrote:
> 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
>>>
>>
>>

Received on Monday, 16 April 2007 20:35:03 UTC