- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Thu, 28 Sep 2006 09:10:20 -0400
- To: ext Sergey Beryozkin <sergey.beryozkin@iona.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "ext Glen Daniels" <gdaniels@progress.com>, <public-ws-policy@w3.org>
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 UTC