W3C home > Mailing lists > Public > public-ws-policy@w3.org > September 2006

Re: NEW ISSUE: Non normative recommendation on calculating effective polices for arbitrary XML elements

From: Sergey Beryozkin <sergey.beryozkin@iona.com>
Date: Mon, 25 Sep 2006 17:36:07 +0100
Message-ID: <001201c6e0c0$b3810e80$3901020a@sberyoz>
To: "Daniel Roth" <Daniel.Roth@microsoft.com>, <public-ws-policy@w3.org>
Hi Daniel

If a given element's policy has a scope which contains a policy subject ( this terminology is a bit tricky for me at the moment :-)), where this policy subject is contained by other policy scopes too, then it seems that in most cases the effective policy of such a subject would be a merge of contained policies.
Section 3.3 says at the moment :

"The precise semantics of how element policy is to be processed once discovered is domain-specific; however, implementations are likely to follow the precedent specified in the section below on WSDL [WSDL 1.1] and Policy." 
So I think Section 3.3 actually advises all other future element attachment scenarios to follow what is advised in that section...

Have you misread it ? If yes and/or you believe there're scenarious when it can not be the case then I'll have no problems with closing this issue as being invalid/resolved.

Thanks, Sergey Beryozkin
  Hi Sergey,

   

  I don't understand the value in making this recommendation.  What is the justification for recommending that all future element attachment scenarios work this way?

   

  Thanks.

   

  Daniel Roth


------------------------------------------------------------------------------

  From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
  Sent: Friday, September 22, 2006 10:39 AM
  To: Sergey Beryozkin; public-ws-policy@w3.org
  Subject: Re: NEW ISSUE: Non normative recommendation on calculating effective polices for arbitrary XML elements

   

  Hi

   

  Few comments on this issue.

   

  I recognize that WS-Policy Attachment section 4.1 [1] describes how an effective policy should be calculated for composite policy subjects like EndpointPolicySubject.

   

  At the same time I feel that the algorithm described in section 4.1 should be actually described in section 3.3 (in a non-normative way) and then should be referred to from section 4.1. 

  The reason for this is that wsdl elements like wsdl:port, etc, are examples of XML elements and section 4.1 shows how policies can be attached to such elements as decribed in section 3.3. In other words, section 4.1 demonstrates how recommendations in section 3.3 can be practically applied. 

   

  Therefore, IMHO it would better if section 3.3 also recommends to use (but not requires) a simple and effective algorithm described in section 4.1 for calclulating effective policies and then have section 4.1 refer to this non-normative text and specify the actual details as applies to WSDL. Doing so would also be beneficial in that other specs and policy authors would likely to follow the same guidelines given that they're described in a more general section 3.3. 

   

  I do not consider this issue be critical but if the group agrees then perhaps the result might lead a minor improvement in the spec

   

  Thanks

  Sergey Beryozkin, Iona Technologies

   

   

  [1] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;%20charset=utf-8#CalculatingEffectivyPolicywithWSDL1.1 

   

    http://www.w3.org/Bugs/Public/show_bug.cgi?id=3723

     

    Target : WS-Policy Attachment, section 3.3

    Justification :
    WS-Policy Attachment, section 3.3 [1] describes how a policy can be associated
    with an arbititrary XML element. This section says : "The precise semantics of
    how element policy is to be processed once discovered is domain-specific;
    however, implementations are likely to follow the precedent specified in the
    section below on WSDL [WSDL 1.1] and Policy."
    The referenced section (see [2] for ex) describes how WSDL element policies are
    processed and how they should be merged so that an effective policy for a
    corresponding policy subject be calcualted.
    This can be generalized in section 3.3 as a non-normative recommendation.

    Proposal :
    Add to section 3.3 a non-normative recommendation(or clarification) on how
    effective polices should be calculated when a policy is associated with an
    arbitrary XML element. It can be added after the following text :

    "The precise semantics of how element policy is to be processed once discovered
    is domain-specific; however, implementations are likely to follow the precedent
    specified in the section below on WSDL [WSDL 1.1] and Policy ...".

    Like this :

    " which follows this non-normative recommendation : When attaching a policy to
    an XML element, a policy scope SHOULD be implied for that attachment. The
    policy scope SHOULD contain the policy subject associated with that element and
    not those associated with the children of that element."
    this is a key addition (several options are possible, whichever is
    simplier/better):

    "An effective policy for a contained policy subject SHOULD be calculated by
    merging an element policy of *this* xml element with any other element policies
    whose policy scope contains the same policy subject"

    If we take WSDL' EndpointPolicySubject [2] as a fictitious example and say we
    take a wsdl:port as an arbitray XML element to which a policy is attached, then
    according to this non-normataive recommendation an effective policy for
    EndpointPolicySubject  will be a merge of wsdl:port, wsdl:binding and
    wsdl:portType, which is what [2] describes.

    Now, just as an example, let's have a look at an EPR as an arbitrary XML
    element with a policy attached inside, perhaps as a first child of epr metadata
    element[3]. EPR identifies an EndpointPolicySubject, specifically it might be
    assumed it maps to wsdl:port. According to this non-normative recommendation an
    effective policy for identified subject will be a merge of a policy attached to
    EPR + wsdl:binding + wsdl:portType which is consistent with [2]
    Please note that an EPR example is just an example. Relevant sections or
    specifications may decide that in case of EPR no merge is needed with
    wsdl:portType and wsdl:binding for an effective policy be calculated, that is
    its attached policy will be a single element policy which will be used to
    calculate an effective policy for a corresponding policy subject

    [1]
    http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;%20charset=utf-8#XMLElementAttachement 
    [2]
    http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;%20charset=utf-8#EndpointPolicySubject
    [3]
    http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0028.html
Received on Monday, 25 September 2006 16:35:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:41 GMT