- From: Daniel Roth <Daniel.Roth@microsoft.com>
- Date: Wed, 30 Aug 2006 10:58:35 -0700
- To: "Glen Daniels" <gdaniels@sonicsoftware.com>, <public-ws-policy@w3.org>
Hi Glen, Below you mention that "there are potentially serious interoperability concerns here..." Could you please elaborate on this point? What are the interoperability issues and how do you think they would play out? Thanks. Daniel Roth -----Original Message----- From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Glen Daniels Sent: Wednesday, July 12, 2006 7:57 PM To: public-ws-policy@w3.org Subject: NEW ISSUE: Semantics of successful intersection determined by domain-specific assertion content Description: 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. 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. Thanks, --Glen [1] http://www.w3.org/Submission/WS-Policy/#Policy_Intersection
Received on Wednesday, 30 August 2006 17:59:11 UTC