Re: [Bug 4554] Configurability and comformance of intersection algorithm

Asir Vedamuthu wrote:
> [Using plain text format]
>
>   
>> Is there a worked-through example of where and how the result of intersection would be useful?
>>     
>
> The Primer carries such an illustrative example in Section 3.4 [1].
>   
This example only seems to discuss the result of checking compatibility,
not the literal result of the intersection.  In fact, it does not even
show the result of the intersection, nor does it discuss the
significance of, say, wsap:UsingAddressing appearing twice (and not
once) in the intersected result.

What I was after was something that would actually compute the
intersection as described in 4.5 and use it in some way.  This would
help explain why intersection is defined as a commutative operator and
why alternatives are combined by bag union.

As far as I can tell, the actual use cases for intersection involve only
checking whether the intersection is non-empty or (I think) determining
which of a client's alternatives are compatible with at least one of the
service's alternatives.  Neither of these relies on the literal result
of the intersection.

I also note something that I overlooked on first reading this section,
namely the description of how policy expressions map to policies.  I
would think that this should be in the framework proper and not the
primer, but in any case it fills in the missing piece of semantics.  To
find the policy expressed by a given expression:

    * Find a normal-form expression equivalent to the given expression
      using the rules called "commutative" etc.  (are there any fully
      worked-through examples of this?).
    * Read off the policy using the rules given here.

I believe this was the intent all along, but the current spec only gives
the reverse mapping from policies to equivalence classes of expressions
(and that only informally), and of course that tacitly assumes that this
mapping is one-to-one.

As I've said, it seems much simpler to dispense with the normalization
rules and define the mapping from policy expressions to policies
directly, but since the text is already written it would at least be
helpful to make it normative.
> [1] http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/#compatible-policies
>
>   
>> If not, I would expect to see OPTIONAL.
>>     
>
> Okay. How about - 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./
>
>   
Editorial note:  Here and elsewhere I would drop phrases like "useful"
and "simple".  This is not a knock against WS-Policy.  It's just good
practice to let readers make up their own minds on such matters.  If
they agree, such adjectives are redundant; if not, they are irritating
at best.  We can already assume /you/ like WS-Policy :-).

That aside, I want to double-check that you really mean OPTIONAL. 
OPTIONAL here would mean that WS-Policy processors don't have to
implement intersection.  That is, a toolkit can say "we support
WS-Policy" without implementing intersection.

>From elsewhere in this thread, I suspect you may intend that the /use/
of intersection is optional.  That is, if I want to determine whether a
service's policy lets me do what I want to do, I might do this by
constructing a policy representing my desires and then intersecting it
with the service's policy, or I might do it some other way.

I'm interested in the former here: what functionality MUST a WS-Policy
compliant processor provide?
>> IMO it would be less confusing to say "This is the default policy
>> intersection behavior" instead of calling it an approximation.
>>     
>
> The policy intersection is OPTIONAL and is a QName based approximation. Given these, the policy intersection cannot be labeled as the default.
>   
It's still not clear to me what the operation described in 4.5 is an
approximation /of./  The language suggests that there is some "correct"
notion of intersection and that the operation defined produces results
in some way close to the correct ones.  For example, I could define an
approximation of the cosine function and assert that its results are
always within .01 of the actual cosine.

What seems to be going on here, I think, is that absent other
information, intersection means what's in 4.5, but that vocabulary
authors may define different behavior.  To me, that's a default that may
be overridden.

This seems to be mostly a matter of wording.  The more important
question is "In what ways is the default behavior allowed to be
overridden?", or if you prefer "In what ways may actual behavior differ
from the approximation?"

>From the current text I see no limits, which is worrisome.  If clients
come to use intersection in particular ways, authors will try not to
break this, but the whole point of having a standard is to agree on the
rules up front.  If there are no a priori restrictions, then it might be
better to move intersection into the primer.


>> By default ("approximation"?) assertions marked ignorable participate
>> in strict intersection but not in lax intersection.  Could I define a
>> new assertion and state "this assertion MUST be considered in lax
>> intersection, even if marked ignorable?"  (I would hope not.  It would
>> be clearer in such a case to say "this assertion MUST NOT be marked ignorable")
>>     
>
> Your observation is correct. In this case, the onus is on the assertion author. If an assertion author wants an assertion to be processed by policy intersection the assertion should not be marked ignorable. This is a good point that we could cover in the Guidelines for Assertion Authors document.
>   
The question is not whether or not this is a good idea, but whether it's
allowed.  I see no statement that authors MUST NOT do such a thing.

The larger question is "What assumptions can someone using intersection
make?"  In this particular case, can one assume that ignorable=true will
always be respected?
>   
>> What if an alternative contains assertions from two different
>> vocabularies, each with its own domain-specific rules, and these rules
>> conflict in some way?
>>     
>
> Possible. We think assertion authors should avoid defining conflicting domain specific intersection rules. If there are any conflicting rules, implementers should provide feedback to the assertion authors. This is also a good point that we could cover in the Guidelines for Assertion Authors document.
>   
It would also be worth stating in the framework that authors SHOULD NOT
define conflicting rules.
> Regards,
>
> Asir S Vedamuthu
> Microsoft Corporation
>
>
>
>
>
>
>
>
> From: David Hull [mailto:dmh@tibco.com]
> Sent: Wednesday, May 16, 2007 8:58 PM
> To: Asir Vedamuthu
> Cc: Paul Cotton; public-ws-policy@w3.org
> Subject: Re: [Bug 4554] Configurability and comformance of intersection algorithm
>
> Asir Vedamuthu wrote:
> It's not clear that they're even
> obligated to support the "approximation".
>
>
> 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.
>
> Yes, about that: Is there a worked-through example of where and how the result of intersection would be useful?  By "result" I mean literally the result.
>
> The framework speaks of checking whether the intersection of two policies is empty, and the primer refers to  using intersection to learn which desired alternatives are compatible with a given policy.
>
> As far as I can this compatibility checking is the useful functionality, indeed the whole point of having a policy framework in the first place.  Given this, it doesn't seem to matter whether policies and alternatives are bags or sets, or whether the "intersection" of two alternatives is the bag union, the set union or simply a boolean that says whether they were compatible.
>
>  The use of policy intersection is optional.
>
> By "use", do you mean "use by client code" or "support by processors"?  Does "I support WS-Policy" mean "I support the version of intersection given in section 4 of the framework (and possibly some extensions)"?  If so, I would expect to see an RFC2119 MUST somewhere in that section.  If not, I would expect to see OPTIONAL.
>
> The use of "approximation" is also unsettling
>
>
> It is a QName based approximation. If implementers would like to use policy intersection as the default algorithm they are free to make it so.
>
> The point is that, from a literal reading, it doesn't seem that the framework defines policy intersection at all.  It defines an operation that is said to be an approximation of it, but it doesn't define the operation itself.
>
> I believe this is a purely editorial issue; clearly the framework defines something.  IMO it would be less confusing to say "This is the default policy intersection behavior" instead of calling it an approximation.  I'm also arguing that it should go on to define in what ways this default behavior may be modified and the result still be called policy intersection.
>
>
>
> Should there be different behavior for strict and lax modes, or can it
> be ignored for a given vocabulary?
>
>
> We think you are referring to the behavior implied by an assertion. If so, the behavior implied by an assertion is independent of the chosen intersection mode.
>
> No, that's not what I mean.
>
> By default ("approximation"?) assertions marked ignorable participate in strict intersection but not in lax intersection.  Could I define a new assertion and state "this assertion MUST be considered in lax intersection, even if marked ignorable?"  (I would hope not.  It would be clearer in such a case to say "this assertion MUST NOT be marked ignorable")
>
> Or, could I say "If this assertion is marked ignorable, it MUST be considered incompatible with assertion XYZ regardless of the value of the ignorable attribute"?  That is, I'm disabling the strict/lax distinction but only in certain cases.
>
>
>
> What if an alternative contains assertions from two different
> vocabularies, each with its own domain-specific rules, and these rules
> conflict in some way?
>
>
> Possible. We think assertion authors should avoid defining conflicting domain specific intersection rules. If there are any conflicting rules, implementers should provide feedback to the assertion authors.
>
> That seems reasonable, and worth an RFC 2119 SHOULD NOT.
>
>
> We hope this helps.
>
> Regards,
>
> Asir S Vedamuthu
> Microsoft Corporation
>
>
> -----Original Message-----
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Cotton
> Sent: Sunday, May 13, 2007 12:20 PM
> To: public-ws-policy@w3.org
> Cc: dmh@tibco.com
> Subject: [Bug 4554] Configurability and comformance of intersection algorithm
>
>
>
> -----Original Message-----
> From: public-ws-policy-qa-request@w3.org [mailto:public-ws-policy-qa-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
> Sent: May 11, 2007 11:47 AM
> To: public-ws-policy-qa@w3.org
> Subject: [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?
>
>
>
>
>