Re: policy vocabulary, will not be applied, oh my!

Hi Chris

Would it be possible to post an example which would show a realistic scenario where it's obvious the fact that the input policy vocabulary is not included in the effective policy's vocabulary may cause the problems for a client ? I just find it difficult to understand the reasoning when policies A&B are used in examples :-)

Also, I don't understand why the client can not use the effective policy's vocabulary as the guidance on what assertions can be applied. The fact that many more assertions might've been involved in the intersection seems unimportant to me, the client can not apply what the effective policy has now, that is whatever assertions are in the selected alternative. I think this is what Monica said in the other email (sorry if misinterpreted that email reply).

I hope the practical example will help to understand the problem better

Thanks, Sergey
  ----- Original Message ----- 
  From: Christopher B Ferris 
  To: public-ws-policy@w3.org 
  Sent: Tuesday, May 01, 2007 9:22 PM
  Subject: policy vocabulary, will not be applied, oh my!



  There are some related issues/questions/concerns that have been expressed by members 
  of the WG with regards the framework specification as it relates to the "will not be applied" principle 
  and the definions for "policy vocabulary", etc. Below, I have enumerated these issues 
  and suggest a path forward to address those concerns. 

  1. The definition of "policy vocabulary" is incompatible with intersected policy as regards to 
  the "will not be applied" principle because post intersection, the resultant policy expression 
  does not carry the policy vocabulary of the input policy expressions. Hence, if a provider 
  had two alternatives, one with Foo and one without Foo, and the result of intersection determined 
  that the alternative without Foo was compatible with a client's policy, then the resultant 
  policy expression would not have in its vocabulary (as computed using the algorithim 
  currently specified) Foo and hence it would not be clear whether Foo carries with it 
  the "will not be applied" semantic. 

  Action-283 - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0103.html 
  Action-284 - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0106.html 
  Ashok email - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0065.html 

  2. There is a degree of confusion regarding the "will not be applied" semantic as it applies to nested policy. 
  This is related to the interpretation of "policy vocabulary" that many held prior to the clarification provided by 
  Microsoft 

  Asir's email on nested policy vocabulary - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0017.html 

  3. As a result, a number of email threads have sprung up that question the merits of the "will not be applied" 
  semantic. 

  Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0065.html 
  Dale - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0075.html 
  Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0101.html 
  Dale - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0108.html 

  It may be that the most prudent course forward would be to drop the "will not be applied" semantic as relates 
  policy vocabulary. As a result, there is little need of a normative definion for policy vocabulary or policy alternative 
  vocabulary, as these definitions only served to allow one to determine whether the behavior implied by a 
  given assertion carried the "will not be applied" semantic. 

  Instead, we could simply state that the behavior implied by an assertion that is absent from a given alternative 
  is not to be applied in the context of the attached policy subject when that alternative is engaged. 
  This would provide clearer semantic (I believe) to borth assertion and policy authors. 

  The attached mark-up of the policy framework specification contains the changes that I believe would 
  be necessary to affect this change. 

  Impact analysis: 

  - The proposed change does not affect the XML syntax 
  - Nor does it impact the semantics of the namespace, therefore the namesapce URI can remain unchanged 
  - It does not affect the processing model (normalization, intersection) 
  - It does not impact testing results to date 
  - It does not affect any of the assertion languages developed to date 

  The related questsion that needs to be asked should we choose to adopt this proposal is: 

          Does this change affect any implementations? 

  From analysis of the set of test cases, the answer is not clear, because there were no tests that 
  excercised either policy vocabulary or the "will not be applied" semantic. Thus, it would be important that 
  we check our respective implementations to ascertain whether there would be any impact. From an IBM 
  perspective, this change does not impact our implementation. 



  Cheers, 

  Christopher Ferris
  STSM, Software Group Standards Strategy
  email: chrisfer@us.ibm.com
  blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
  phone: +1 508 377 9295