This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 4.4 of the WS-Policy spec [1] states that domain-specific processing may need to be performed in order to determine the intersection of two policies. This means that generic Policy processors (tools, etc) cannot have any guarantee of successfully calculating the intersection without appropriate extensions/plugins being available for all domain-specific assertions.
Topic: Semantics of successful intersection determined by domain-specific assertion content Description: Section 4.4 of the WS-Policy spec states that domain-specific processing may need to be performed in order to determine the intersection of two policies. This means that generic Policy processors (tools, etc) cannot have any guarantee of successfully calculating the intersection without appropriate extensions/plugins being available for all domain-specific assertions. Justification: There are potentially serious interoperability concerns here, since building a general-purpose Policy processor which reliably computes intersections is impossible without some indication that assertions do (or do not) augment the semantics. Proposal: The solution space here seems to work out like this - 1) Leave it as-is. 2) Remove the ability for domain-specific logic to affect intersection, and only use top-level QName matching. This would simplify the algorithm and allow interoperability, but at the cost of disabling some powerful functionality for domain authors. 3) Since WS-Policy is a generic framework, it should be possible to at least *know* when particular assertions are going to affect the intersection semantics. It would be fairly easy to have a "wsp:custom" (not necessarily the best name) attribute on assertions, which when "true" would indicate that the marked assertion does alter/augment intersection semantics. In that case, the processor would be able to recognize when it has the correct plugins, and when it cannot deliver a reliable intersection. This is analagous to soap:mustUnderstand and wsdl:required - an indication that an extension may change the rules in ways that must be agreed upon for success. I therefore propose we begin discussion, with a preference to explore solution #3.
From Fabian Ritzmann and Monica J. Martin (fabian.ritzmann@sun.com, monica.martin@sun.com) See: http://lists.w3.org/Archives/Public/public-ws-policy/2006Aug/0138.html The task of finding appropriate extensions/plugins for intersection is complicated by the fact that any policy processor needs to iterate through every single assertion in the policy in order to determine the vocabulary and the domains used in the policy. Have we considered stating the domains a policy up front? Hopefully we can start to engage this discussion today. Thanks. Fabian Ritzmann Monica J. Martin
Resolved at Sept F2F meeting: http://www.w3.org/2006/09/13-ws-policy-minutes.html Add text like the following to the Framework: a) If domain-specific intersection alg is required you will know that by lookig at the Qname. b) If domain-specific intersection alg is required you will know that by lookig at the Qname.