- From: Prasad Yendluri <prasad.yendluri@webmethods.com>
- Date: Mon, 9 Oct 2006 11:43:15 -0700
- To: Ashok Malhotra <ashok.malhotra@oracle.com>, Paul Cotton <Paul.Cotton@microsoft.com>, Sergey Beryozkin <sergey.beryozkin@iona.com>, public-ws-policy@w3.org
- Message-ID: <A3E375FA108EF94496269A5A96AFCAC106E3AC44@mailwest-e0b>
Hi Ashok et al, _____ From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Ashok Malhotra Sent: Friday, October 06, 2006 3:51 PM To: Paul Cotton; Sergey Beryozkin; public-ws-policy@w3.org Subject: RE: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requeste I'm sorry, but I disagree with this direction. wsp:Optional is orthogonal to assertions that that have no behavioral requirements (or do not affect the wire format). PY>I agree with this. wsp:Optional is used to indicate that an assertion may or may not be used. For assertions that do not affect the wire format this has no meaning. PY> I agree with the 1st sentence but not the 2nd. I don't think we can make a blanket statement that it has no applicability (meaning). That depends IMO. Marking assertions "optional" makes sense for some and for others it would not, based on the nature of the assertion itself, orthogonal to, if it has wire manifestations or not (as you stated in your 1st paragraph above). These assertions are in some sense just advertising. The provider says "I will keep yr information confidential" -- well fine, but how would Optional apply to such an assertion or, more strongly, make sense with such an assertion. Would you want two alternatives that say keep it confidential and don't keep it confidential? OK. If you want that you can say that but that has no relation to whether the assertion impacts the wire format or not. I support an attribute that marks such assertions as "non-operational" and so takes them out of the intersection algorithm. This would simplify policy processing. PY>I agree that it would be useful to have a flag such as "wsp:advisory" / "wsp:ignorable" to mark such assertions that the interacting party side can safely ignore (and factor out of intersection algorithm etc.). Regards, Prasad All the best, Ashok _____ From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Cotton Sent: Friday, October 06, 2006 10:57 AM To: Sergey Beryozkin; public-ws-policy@w3.org Subject: RE: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requeste >1. Add an example to a primer and/or policy guidelines Can you formulate your required example even in outline form? >2. Explain why policy authors should make such assertions optional for those requesters which are not aware of them. I assume you want this text in the primer and/or guidelines doc. Is that correct? If so can you offer proposed text? > 3. Make any necessary changes to the wsp:optional related wording so that a policy author can use wsp:optional as a recognized but not a workaround way to mark such assertions. Can you please clarify what you mean by "so that a policy author can use wsp:optional as a recognized but not a workaround to mark such assertions"? Are you saying the Framework should warn policy assertion authors from using wsp:optional to describe "assertions with no behavioural requirements on the requester"? /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (613) 225-5445 Fax: (425) 936-7329 mailto:Paul.Cotton@microsoft.com <mailto:Paul.Cotton@microsoft.com> _____ From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin Sent: October 6, 2006 6:27 AM To: Sergey Beryozkin; public-ws-policy@w3.org Subject: Re: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requeste Hello, This is the resolution I think would adequately address this issue : 1. Add an example to a primer and/or policy guidelines 2. Explain why policy authors should make such assertions optional for those requesters which are not aware of them. 3. Make any necessary changes to the wsp:optional related wording so that a policy author can use wsp:optional as a recognized but not a workaround way to mark such assertions. Thanks, Sergey http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789> Target : WS-Policy Framework and policy guidelines Justification : There's a class of policy assertions which have no behavioral requirements on the requester but can be still usefully processed by requesters which are aware of what assertions mean. For example : <oasis:Replicatable/> An assertion like this one can be a useful source of information for requesters. Providers having expected properties like <oasis:Replicatable/> can be chosen/searched. At the same time, given the fact assertions like <oasis:Replicatable/> have no behavioral requirements on the provider it's important to ensure policy-aware clients which have no knowledge of these assertions can proceed consuming the service advertsing this assertion. Currently the way to advertise such an assertion is to use a normal form with two policy alternatives(simple case), with only one alternative containing this assertion thus making it optional, or, in other words, giving a chance to requesters to ignore it. Such normal form expression is equivalent to a compact form with the optional assertion marked with wsp:optional attribute with a value 'true'. However, at the moment the primer recommends using wsp:optional when one needs to mark asssertions which identify optional capabilities/requirements with behavioral requirements on a requester should the requester wishes to use it. Thus marking assertions like <oasis:Replicatable/> with wsp:optional is considered to be a wrong approach. Proposal : Clarify the text describing the optionality in the policy guidelines and in the Framework spec on how a policy author should use assertions like <oasis:Replicatable/>. It's important that assertions like these can be usefully interpreted by knowledgeble requesters and safely ignored by requesters unaware of them.
Received on Monday, 9 October 2006 18:44:20 UTC