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