This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A generic policy processor cannot distinguish from an XML element by itself whether it is an assertion or a parameter, yet they are treated differently in intersection operations. For this reason the Framework specification must distinguish the two. Justification - A generic policy processor should be able to perform generic iintersection operations on policy without knowledge of every possible policy domain. This allows extensibility. In addition, the normalization algorithm needs to explicitly account for passing through parameter elements. Target - WS-Policy Framework [1] Proposal - add requirement statement to Framework document, and update examples correspondingly: "Every assertion must be the direct child of a wsp:Policy element, and every parameter element must not be a direct child of a wsp:Policy element." Change step 3.2 of 4.2 normalization procedure to be: "2. If the Element Information Item C is a child of a Policy element; normalize C per Sections 4.3.1 Optional Policy Assertions and 4.3.2 Policy Assertion Nesting. Otherwise, copy Element C to the output." Test1: The following two assertions should match: <wsp:Policy xmlns:ex="http://www.example.com/example" xmlns:foo="http://www.example.com/parameter" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > <ex:Example > <foo:Something /> </ex:Example> </wsp:Policy> <wsp:Policy xmlns:ex="http://www.example.com/example" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > <ex:Example > </ex:Example> </wsp:Policy> Test2: If it is known that foo:Something is an assertion, then a processor that is able to perform validity checking should flag an error. This may require an implementation that accepts a list of known assertions as an input for validity checking.
From: Asir Vedamuthu <asirveda@microsoft.com> http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0084 > A generic policy processor cannot distinguish > from an XML element by itself whether it is > an assertion or a parameter Let us look at the distinction at the XML representation level: Policy Assertion - A child element of the Policy, All or ExactlyOne element that is not from the WS-Policy XML namespace is a policy assertion. Policy Assertion Parameter - A child element or an attribute of a policy assertion element that is not from the WS-Policy XML namespace is a policy assertion parameter. Given these, the distinction between an assertion and a parameter is unambiguous for machines that read a policy expression. There are test cases that use assertions and assertion parameters in the contributed interop scenarios pack [1]. Several implementers ran these test cases. I am not aware of any related interop issues. [1] http://lists.w3.org/Archives/Public/public-ws-policy/2006Jun/0010.html > normalization algorithm needs to > explicitly account for passing > through parameter elements. Policy assertion parameters are the opaque content (or payload) of an assertion. Parameters carry additional useful information for engaging the behavior described by an assertion and are preserved through policy processing such as normalize and merge. For normalization, I am not aware of a need for passing through parameter elements.
Asir Is it correct to use namespaces to distinguish policy assertions from parameters, since assertions may also be defined in arbitrary domain policy namespaces, not known to the generic policy processor? The definitions indicate that every assertion must be the child of a wsp:Policy element and every parameter only the child of an assertion, so we are in agreement here.
see also email http://lists.w3.org/Archives/Public/public-ws-policy/2006Aug/0063.html
See http://lists.w3.org/Archives/Public/public-ws-policy/2006Aug/0117.html for updated proposal.
Proposal to make changes to Framework as outlined in email message http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0038.html accepted by working group to close issue with editor action. Minutes: http://www.w3.org/2006/09/13-ws-policy-irc#T21-53-24