Re: What is the Vocabulary of an Intersected Policy

I agree with the point that David is making. There are two aspects of 
this discussion, and Ashok's original question that should be 
differentiated:

   1. Vocabulary of the effective policy: Is this the vocabulary scoped
      to the effective policy or the union of the vocabularies that
      input into the effective policy?
   2. Application of the effective policy: It may be prudent to separate
      this sentence from what the constraint is.

        "When an assertion whose type is part of the policy's vocabulary
        is not included in a policy alternative, the policy alternative
        without the assertion type indicates that the assertion will not
        be applied in the context of the attached policy subject."

This indicates the assertion will not be applied not that there is an explicit constraint or restriction to doing so (i.e. this Framework text is descriptive in nature rather than RFC language that dictates required functionality). This is not an opinion of what it could/should indicate or dictate to an implementation, or the value of considering or including in future work a NOT operator. What it does evidence is we should be explicit about our intent. When we discussed this at length before (when this text was changed) and even earlier (remember WS-TX discussions on wsp:Optional), this conflict of text and its intent existed. Now we revisit it again with more impact seen for other domains, including WS-Addressing.  
  

Thanks.

>orchard: ...The fact that C wasn't selected is a different fact than C isn't in the vocabulary.
>sergey2: ...I don't understand why having C&D in the vocabulary of the effective policy will help to avoid applying them. 
>...	 
>sergey: My understanding is that A&B is the vocabulary of the final effective policy, the fact that this policy was computed through the intersection is not important		 
>
>		"BUT, Chris points out the vocabulary should be
>{A,B,C,D} to remember the fact that this was the union of the
>vocabularies of the two intersected policies and that {C. D} must not be
>applied since they were not selected."		 
>
>		I don't understand. Why would the consumer need to keep
>C&D in the vocabulary of the effective(calculated through the
>intersection) policy if they can't be appplied ?
>  
>
malholtra: ...Subject: What is the Vocabulary of an Intersected Policy
We spoke briefly about this on the call today and I see a problem. This note is an attempt to state the problem clearly.

Consider two normalized policies
<Policy>
    <ExactlyOne>
        <All>
              <A/>
               <B/>
        </All>
         <All>\
                <C/>
         </All>
      </ExactlyOne>
</Policy>

<Policy>
    <ExactlyOne>
        <All>
              <A/>
               <B/>
        </All>
         <All>\
                <D/>
         </All>
      </ExactlyOne>
</Policy>

Let us intersect these two policies.  What we get is:

<Policy>
    <ExactlyOne>
        <All>
              <A/>
               <B/>
        </All>
    </ExactlyOne>
</Policy>

Now, what is the vocabulary of this policy?  Looking at this policy alone it should be { A, B}.
BUT, Chris points out the vocabulary should be {A,B,C,D} to remember the fact that this was the union of the vocabularies of the two intersected policies and that {C. D} must not be applied since they were not selected.

This seems like a contradiction.   To remember the negative decision we need to include assertions that are not in the policy, in its vocabulary.

SOLUTIONS:
The only viable solution that I can see is to drop the 'negation' semantic, namely, "When an assertion whose type is part of the policy's vocabulary is not included in a policy alternative, the policy alternative without the assertion type indicates that the assertion will not be applied in the context of the attached policy subject."   (Dale was arguing for this on other grounds as well)  Some would object strongly to this.  A counter proposal would be to add an explicit NOT operator.

Unfortunately, these are radical suggestions but I do not see any other way out.   
All the best, Ashok

Received on Thursday, 19 April 2007 16:46:05 UTC