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

+1 to the analysis of Chris and the idea to drop the "will not be applied"
semantics. Also, I think this resolution would have no impact on the WS
Addressing assertion described at
http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/att-0094/WSAddrPolicyAlgerntiveGprime.htm
.

Regards, Felix.

> 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

Received on Wednesday, 2 May 2007 09:26:19 UTC