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

Thanks, Monica!  Your explicit wording is better.

All the best, Ashok

> -----Original Message-----
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of Monica J. Martin
> Sent: Tuesday, May 08, 2007 8:45 AM
> To: Ashok Malhotra
> Cc: Christopher B Ferris; public-ws-policy@w3.org
> Subject: Re: policy vocabulary, will not be applied, oh my!
> 
> 
> 
> >Ashok Malhotra wrote: Chris:
> >My preference is not to include the last sentence.  So, there are no
> claims re. the assertions not included in the alternative.
> >
> >The revised paragraph reads:
> >
> >[Definition: A policy alternative is a potentially empty collection of
> policy assertions <http://www.w3.org/TR/2007/CR-ws-policy-
> 20070330/#policy_assertion> .] An alternative with zero assertions
> indicates no behaviors. An alternative with one or more assertions
> indicates behaviors implied by those, and only those assertions.
> >
> >
> mm1: Although we may need to revise this text to accommodate deletion of
> x.vocabulary, the Primer, Section 2.6 includes similar language to what
> you ask Ashok. Why can't we be explicit about this, if that is the WG
> preference?
> 
>     ..."When a policy assertion is absent from a policy vocabulary (See
>     section 3.2, Web Services Policy 1.5 - Framework), a policy-aware
>     client should not conclude anything (other than 'no claims') about
>     the absence of that policy assertion."
> 
> Related to this discussion we also have (now in Section 2.11):[2]
> 
>     The absence of policy expressions, for example, in a WSDL document
>     does not indicate anything about the capabilities and requirements
>     of a service. The service may have capabilities and requirements
>     that can be expressed as policy expressions, such as the use of
>     addressing, security and optimization. Or, the service may not have
>     such capabilities and requirements. A policy aware client should not
>     conclude anything about the absence of policy expressions.
> 
> [1]
> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-
> primer.html?content-type=text/html;%20charset=utf-8#optional-policy-
> assertion
> [2]
> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-
> primer.html?content-type=text/html;%20charset=utf-8#attaching-policy-
> expressions-to-wsdl
> (Note change as a result of Issue 4288:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4288).
> 
> >All the best, Ashok
> >
> >________________________________
> >
> >From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of Christopher B Ferris
> >Sent: Tuesday, May 08, 2007 5:01 AM
> >To: public-ws-policy@w3.org
> >Subject: Re: policy vocabulary, will not be applied, oh my!
> >
> >
> >
> >
> >All,
> >
> >I've been thinking about this, and possible language that would make
> things clear to the reader that an alternative's set of
> >assertions implies that ONLY those behaviors implied by those assertions
> are applied in the context of an interchange
> >governed by that policy alternative.
> >
> >Also, since there isn't an issue to go with this thread, and it may well
> end up with CR edits to the
> >spec, I opened an issue (4544) in Bugzilla:
> >
> >        http://www.w3.org/Bugs/Public/show_bug.cgi?id=4544
> >
> >The first paragraph in section 3.2 of the Framework currently reads:
> >
> >[Definition: A policy alternative is a potentially empty collection of
> policy assertions <http://www.w3.org/TR/2007/CR-ws-policy-
> 20070330/#policy_assertion> .] An alternative with zero assertions
> indicates no behaviors. An alternative with one or more assertions
> indicates behaviors implied by those, and only those assertions.
> [Definition: A policy vocabulary is the set of all policy assertion types
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion_type>
> used in a policy.] [Definition: A policy alternative vocabulary is the set
> of all policy assertion types <http://www.w3.org/TR/2007/CR-ws-policy-
> 20070330/#policy_assertion_type>  within the policy alternative
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_alternative> .]
> When an assertion whose type is part of the policy's vocabulary is not
> included in a policy alternative, the policy alternative without the
> assertion type indicates that the assertion will not be applied in the
> context of the attached policy subject. See the example in Section 4.3.1
> Optional Policy Assertions <http://www.w3.org/TR/2007/CR-ws-policy-
> 20070330/#Optional_Policy_Assertions>
> >
> >I would propose the following change:
> >
> >[Definition: A policy alternative is a potentially empty collection of
> policy assertions <http://www.w3.org/TR/2007/CR-ws-policy-
> 20070330/#policy_assertion> .] An alternative with zero assertions
> indicates no behaviors. An alternative with one or more assertions
> indicates behaviors implied by those, and only those assertions. No other
> behaviors are to be applied for the alternative.
> >
> >The rest of the edits in the original proposal [1] remain unchanged.
> >
> >[1] http://lists.w3.org/Archives/Public/public-ws-
> policy/2007May/0003.html
> >
> >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
> >
> >public-ws-policy-request@w3.org wrote on 05/07/2007 09:07:16 AM:
> >
> >
> >
> >>+1,
> >>
> >>(Thanks Chris, for providing an example. Makes it much clearer for
> >>understanding issue.)
> >>
> >>regards, Frederick
> >>
> >>Frederick Hirsch
> >>Nokia
> >>
> >>
> >>On May 2, 2007, at 5:19 AM, ext Sergey Beryozkin wrote:
> >>
> >>
> >>
> >>>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
> >>>
> >>>
> >>
> >>
> >
> >
> >
> 
> 
>

Received on Tuesday, 8 May 2007 16:08:02 UTC