Re: Bug 4584 : Clarify how lax mode and ignorable assertions affect the intersection algorithm

Sergey,

As I indicated, the intersection result includes all assertions from the 
compatible alternatives
regardless of whether or not they are marked ignorable. It does not matter 
which
policy includes such alternatives.

More comments below.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

public-ws-policy-request@w3.org wrote on 05/25/2007 06:17:02 AM:

> Consider the following two policies.
> 
> Provider policy :
> <Policy>
>  <A/>
>  <B wsp:ignorable="true"/>
> </Policy>
> 
> Requester policy :
> <Policy>
>  <A/>
>  <D wsp:ignorable="true"/>
> </Policy> 
> 
> Requester initiates the intersection, lax mode is on.
> 
> I believe the following clarification should be made :
> 1. If the entity which initiates the intersection contains 
ignorableassertions
> then such assertions must be treated as normal non-ignorable assertions, 
that
> is, the requester's policy is equivalent in this case to
> 
> <Policy>
>  <A/>
>  <D/>
> </Policy>

How they are treated with regards to engaging behavior in an interaction
is not relevant to intersection. Intersection is all about determining
whether two policies are compatible. 

> 
> Lax mode means that the requester may ignore the provider's ignorable

Correct.

> assertions. It does not say anything about including the 
requester'sassertions
> marked as being ignorable into the effective intersected policy.

Actually, it does.
http://www.w3.org/TR/2007/CR-ws-policy-20070330/#Policy_Intersection

"If two alternatives are compatible, their intersection is an alternative 
containing all of the assertions in both alternatives. "

Granted, the language could be a little confusing since it could have been 
read to
mean that only those assertions present in BOTH of the alternatives are 
included in the
result. However, that was not the intent. An inspection of the test cases 
for intersection
should make it clear that the intent was actually that the intersection 
result is the
bag union of the two alternatives.

We have actually cleared this up as a result of resolving one of David 
Hull's issue 4553
        http://www.w3.org/Bugs/Public/show_bug.cgi?id=4553

The new text agreed during this week's f2f is as follows:

"If two alternatives are compatible, their intersection is an
alternative containing all of the occurrences of all of the assertions 
from each of the
alternatives (i.e., the bag union of the two)."

> Ignorable assertion means : you can ignore it for the intersection 
purposes if
> you're in a lax mode, it's the message to the entity initiating the
> intersection.

Correct, you can ignore it for purposes of intersection in lax mode. 
However,
I think you should re-read the intersection algorithm as it applies to 
Ignorable.

Again, quoting from the framework (as amended by the resolution to 4553):

If the mode is strict, two policy alternatives A and B are compatible:
    * if each assertion in A is compatible with an assertion in B, and
    * if each assertion in B is compatible with an assertion in A.

If the mode is lax, two policy alternatives A and B are compatible:
    * if each assertion in A that is not an ignorable policy assertion is 
compatible with an assertion in B, and
    * if each assertion in B that is not an ignorable policy assertion is 
compatible with an assertion in A.

If two alternatives are compatible, their intersection is an an
alternative containing all of the occurrences of all of the assertions 
from each of the
alternatives (i.e., the bag union of the two).

Note that nowhere does it say to remove the assertions marked as 
ignorable. It simply says that
for each assertion that is not ignorable...

Regardless of whether strict or lax mode is used, the result is "an
alternative containing all of the occurrences of all of the assertions 
from each of the
alternatives (i.e., the bag union of the two)."

No statement is made about excluding those assertions that are marked 
ignorable.

> 
> If this clarification is made then the above two policies will not 
intersect
> irrespectively of which side initiates the intersection.

Intersection is not directional.

> 
> Now consider these two policies :
> 
> Provider policy :
> <Policy>
>  <A/>
>  <B wsp:ignorable="true"/>
> </Policy>
> 
> Requester policy :
> <Policy>
>  <A/>
> </Policy> 
> 
> Requester initiates the intersection, lax mode is on. 
> 
> Clarification needs to be done on whether the effective policy after the
> intersection includes <B wsp:ignorable="true"/> or not. If 
ignorablemeans this
> assertion is ignorable for the intersection purposes then why, after the
> intersection engine finishes its job, <B/> would still be there ?

Yes, see above.

I am wondering whether it would be clearer if we were to change the 
definition of
ignorable from:

An ignorable policy assertion is an assertion that may be ignored for 
policy intersection (as defined ...)

to

An ignorable policy assertion is an assertion that may be ignored for 
purposes of 
determining the compatibility of alternatives in policy intersection (as 
defined ...)

Additionally, we could add to section 4.4 text that makes it clear that 
the
behavior implied by an ignorable assertion is expected to be a behavior 
that need not
be engaged for successful interoperation with the entity that includes 
such ignorable 
assertions in its policy.

> 
> If the requester is working in a design mode then I can see the value, 
as the
> (UI) tool may offer a user a chance to decide on what to do with <B/>
> 
> If the requester is an application doing an intersection 
> dynamically, then what
> is the value of keeping </B> after the intersection ?

That is an exercise for the implementation to decide. Maybe, as in the 
example
we use in the Primer, a warning dialog might be displayed to the end used
indicating that the service provider is logging all message traffic.

> 
> 
> Thanks, Sergey Beryozkin