[Bug 4554] Configurability and comformance of intersection algorithm

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4554

           Summary: Configurability and comformance of intersection
                    algorithm
           Product: WS-Policy
           Version: CR
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: dmh@tibco.com
         QAContact: public-ws-policy-qa@w3.org


It is not clear to what extent the intersection algorithm may be extended or
what obligation processors have to support these extensions.

The second paragraph of section 4.5 reads

"... determining whether two policy alternatives are compatible generally
involves domain-specific processing.  If a domain-specific intersection
processing algorithm is required this will be known from the QNames of the
specific assertion types ... As a first approximation, an algorithm is defined
herein that approximates compatibility in a domain-independent manner."

As far as I can tell, the intent here is that the determination of
compatibility is domain-specific, and that by default the rules go by the type
of the assertions in the alternative and in the case of lax mode, whether the
assertions are marked as optional.

However, even this much is not completely clear, as the text mentions
"domain-specific intersection processing".  So conceivably not only the
compatibility of two alternatives but the result of intersecting them if they
are compatible could be domain specific.

The use of "approximation" is also unsettling in a specifications.  I suspect
it might mean "default" here, but I'm not sure.

In any case, it is not at all clear what leeway someone defining a policy
vocabulary has.  Should there be different behavior for strict and lax modes,
or can it be ignored for a given vocabulary?  Must the intersection itself
follow the "all assertions in both alternatives" rule (subject to
clarification, see 4553)?  What if an alternative contains assertions from two
different vocabularies, each with its own domain-specific rules, and these
rules conflict in some way?

Given clear answers to these questions of definition, what obligations are
processors under to support any of this?  It's not clear that they're even
obligated to support the "approximation".  I see no MUST -- perhaps this is
covered under policy attachment or elsewhere?

Received on Friday, 11 May 2007 15:47:38 UTC