RE: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requeste

@font-face { font-family: Tahoma; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: blue; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle17 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } 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).  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. 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.  
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
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 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.