W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2006

Re: ISSUE 3564: Optional Assertions may not be usable in all cir cumstances

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Thu, 28 Sep 2006 09:10:20 -0400
Message-Id: <3FD74547-EDF5-4CE8-9BB8-C416CD31EFA8@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "ext Glen Daniels" <gdaniels@progress.com>, <public-ws-policy@w3.org>
To: ext Sergey Beryozkin <sergey.beryozkin@iona.com>

I think we are getting lost with the words "capability" and  
"requirement" when I suspect the original meaning was very simple:  
clients have capabilities expressed by policy, providers have  
requirements expressed by policy, and an intersection indicates a  
match of capabilities and requirements.

This is different from the concept of a client not needing to process  
or be aware of provider assertions that do not impact what is on the  
wire, and removing/ignoring these advisory assertions from the  
provider policy before/when performing intersection.

However a point made later in the thread indicates that a client  
still must understand these, which I think is also your point Sergey.

Is it worthwhile to mark assertions that do not impact messaging  
(e.g. as advisory or local), thus removing issue of "optional" for  
these, allowing them to be ignored in intersection yet still  
understood legally?

regards, Frederick

Frederick Hirsch
Nokia


On Sep 27, 2006, at 1:31 PM, ext Sergey Beryozkin wrote:

> Hi Frederick
>
>>
>> No, because it is meaningless to "ignore" an assertion that is  
>> always  applied by the provider, even if it is advisory to the  
>> client. In  other words, it is not ignored in associated impact,  
>> even if client  chooses to treat as advisory and "ignore" it.
>
> Would you agree that it would be useful to think of any assertion  
> listed in a given policy as something which is always supported by  
> their provider  ? In other words they're guaranteed to be supported.
> Irrespectively of how assertions are marked they're supported by  
> their provider and not ignored...
>
> Thanks, Sergey
>
>>
>> No, because it is meaningless to "ignore" an assertion that is  
>> always  applied by the provider, even if it is advisory to the  
>> client. In  other words, it is not ignored in associated impact,  
>> even if client  chooses to treat as advisory and "ignore" it.
>>
>> -- non-wire assertion states something will be done (e.g. logging)  
>> -  this happens, so is not optional.
>> -- client views this as advisory, so ignores in making request,  
>> but  this is not the same as assertion being ignored in entire  
>> process.
>>
>> The issue here is that optional has a much different meaning than   
>> advisory.
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>>
>> On Sep 27, 2006, at 12:45 PM, ext Glen Daniels wrote:
>>
>>>
>>> Hi Frederick:
>>>
>>>> It is difficult to combine the concept of optional with its
>>>> normalization implications with flagging items that can be ignored
>>>> without implication of actual impact.
>>>
>>> Why is that?  Optional means that there is both an acceptable
>>> alternative without this assertion, and one with this  
>>> assertion.   Isn't
>>> that the same thing as saying that the item can be ignored at the  
>>> whim
>>> of the consumer?
>>>
>>> This seems true regardless of whether the given assertion has an
>>> "impact" vis. the wire messages.
>>>
>>> --Glen
>>>
>>>
>>
>
Received on Thursday, 28 September 2006 13:11:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:41 GMT