This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4554 - Configurability and comformance of intersection algorithm
Summary: Configurability and comformance of intersection algorithm
Status: RESOLVED FIXED
Alias: None
Product: WS-Policy
Classification: Unclassified
Component: Framework (show other bugs)
Version: CR
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Felix Sasaki
QA Contact: Web Services Policy WG QA List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-11 15:47 UTC by David Hull
Modified: 2007-05-24 02:57 UTC (History)
0 users

See Also:


Attachments

Description David Hull 2007-05-11 15:47:24 UTC
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?
Comment 1 Asir V Selvasingh 2007-05-24 02:53:32 UTC
<cferris> Replace

"Intersection is a commutative function that takes two policies and returns a policy."

With

"Policy intersection is a commutative operation performed on two policies that yields a policy that contains a collection of the compatible policy alternatives. (Note: while policy intersection at times is analogous with set intersection, it does not imply formal set intersection semantics)."

david: if i had had that term i would have had fewer false assumptions

<cferris> RESOLUTION: issue 4555 closed with the above definition for policy intersection added to Terminology section

http://www.w3.org/2007/05/23-ws-policy-minutes.html#item08
Comment 2 Asir V Selvasingh 2007-05-24 02:56:53 UTC
Ignore my previous entry. I mistakenly updated 4554 with 4555 info - Asir
Comment 3 Asir V Selvasingh 2007-05-24 02:57:39 UTC
<cferris> RESOLUTION: issue 4554 is closed with the proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0261.html to change the text in the first paragraph in section 4.5

That is,

s/Policy intersection is a useful tool when two or more parties express policy and want to limit the policy alternatives to those that are mutually compatible./Policy intersection is OPTIONAL and is a useful tool when two or more parties express policy and want to limit the policy alternatives to those that are mutually compatible./

http://www.w3.org/2007/05/23-ws-policy-minutes.html#item08