NEW ISSUE: Semantics of successful intersection determined by domain-specific assertion content


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.


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.


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.



Received on Thursday, 13 July 2006 02:57:07 UTC