Title : Non-normative recommendation(or clarification) on how effective polices should be calculated when a policy is associated with an arbitrary XML element.
 
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