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

I'd also like a primer clarifying and explaining what does it mean, from a requester's point of view, to work with different policy alternatives.
For ex, at the moment, if we have a policy like this :
<wsp:Policy>
   <ExactlyOnce>
       <!-- alt1 -->
       <All>
          <foo/>
       </All>
       <!-- alt2 -->
       <All>
           <bar/>
       </All> 
   </ExactlyOnce>
</wsp:Policy>

then one interpretation can be that by selecting a first alternative a requester is choosing to work with a provider which has no <bar/>.
The primer should explain that two alternatives are two different policy micro-vocabulary instances and that, by choosing the alternative the requester just chooses the vocabulary it understands/prefers.
>From a provider's perspective,  a policy vocabulary is the one which combines the vocabularies of all alternmatives. That is it supports all assertions, even if this assertion is not present in the alternative chosen by a given requester.
For ex:
<wsp:Policy>
   <ExactlyOnce>
       <!-- alt1 -->
       <All>
          <sp:MessageSecurity/>
       </All>
       <!-- alt2 -->
       <All>
           <sp:TransportSecurity/>
       </All> 
   </ExactlyOnce>
</wsp:Policy>

Irrespectively of the alternative chosen the provider retains the 'being secure' capability. Likewise if we have two service endpoints, with one endpoint being annotated with a policy alternative (service metadata) and the other one being not, the second endpoint still posesses the same capabilities as the first endpoint, it's just thes capabilites will have to be discovered out-of-band for the the second endpoint.

Another example :

<wsp:Policy>
   <ExactlyOnce>
       <!-- alt1 -->
       <All>
          <sp:MessageSecurity/>
       </All>
       <!-- alt2 -->
       <All>
           <sp:TransportSecurity/>
       </All>
       <!-- alt3 -->
       <All>
           <oasis:free/> 
           <ExactlyOnce>
             <All> 
                 <sp:MessageSecurity/>
             </All>
             <All>  
                 <sp:TransportSecurity/>
             </All> 
            </ExactlyOnce>  
        </All>
   </ExactlyOnce>
</wsp:Policy>

3 vocabularies are presented. Irrespectively of the alternative/vocabukary chosen, a service provider retains the capability of being free and secure.

Thanks, Sergey


  Hi

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