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: Fri, 22 Sep 2006 18:38:40 +0100
Message-ID: <001b01c6de6d$f0e922d0$3901020a@sberyoz>
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, <public-ws-policy@w3.org>

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

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 


  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

  "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

Received on Friday, 22 September 2006 17:37:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:27 UTC