Re: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requester

Re: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721Hi

"Can you formulate your required example even in outline form?"



Example. A service has a capability to keep the clients' info confidential. This capability has no behavioral requirements on the client and has no wire representations. It wishes to advertize this capability such that those requesters which understand what it means can use it during the intersection stage or as part of a search as a base for choosing this service among similar ones.

Additionally, this service wishes to make itself available to those requesters which has no a priori knowledge of this assertion due to the safe-to-ignore properties of this capability. 



<wsp:Policy>

   <wsp:ExactlyOnce>

        <contoso:infoConfidential wsp:optional="true"/>

   <wsp:ExactlyOnce>

</wsp:Policy>



"I assume you want this text in the primer and/or guidelines doc.  Is that correct?

 If so can you offer proposed text?"



I'd like to see a clarification in the wsp:optional wording which clearly states that wsp:optional is not optional for a provider and that wsp:optional is a hint to a requester that an assertion identifies a requirement which is optional for a requester to do something about it. In case of <contoso:infoConfidential wsp:optional="true"/> it's a requirement to understand what contoso:infoConfidential means.



I'd like to the terminology be updated such that a <contoso:infoConfidential wsp:optional="true"/> does not turn from a capability in a compact form into a requirement in the normal form. Any assertion when looked from a provider's side is a capability.  Any provider's assertion when looked from a requester's side is a requirement on the requester (to understand it, to do something about it).

If the group agrees with the above then I'd ask editors for help in presenting the text in a more readable way.



"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"? "



Thanks, Sergey



  >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.