[Bug 4584] Clarify how lax mode and ignorable assertions affect the intersection algorithm

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

           Summary: Clarify how lax mode and ignorable assertions affect the
                    intersection algorithm
           Product: WS-Policy
           Version: CR
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Primer
        AssignedTo: fsasaki@w3.org
        ReportedBy: sergey.beryozkin@iona.com
         QAContact: public-ws-policy-qa@w3.org


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 ignorable assertions
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>

Lax mode means that the requester may ignore the provider's ignorable
assertions. It does not say anything about including the requester's assertions
marked as being ignorable into the effective intersected policy.
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.

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

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 ignorable means this
assertion is ignorable for the intersection purposes then why, after the
intersection engine finishes its job, <B/> would still be there ?

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 ?

Received on Friday, 25 May 2007 10:08:29 UTC