Title: Proposal for AI 286
Target: Guidelines section 5.4.2 

Description: There has been an ongoing action to deal with the Guidelines document with regard to things we have learned from the WS-Addressing groups efforts to create new assertions. Monica had floated several proposals dealing with context and vocabulary.I tried to incorporate this input into the sections 5.4.2 "Nested Assertions" and Section 8 "Designing Assertions".
There is a separate bug for Section 8.


Proposal: 
---------------------------------------------------------------------------
<change from>
5.4.2 Nested Assertions
The framework provides the ability to "nest" policy assertions. For domains with a complex set of options, nesting provides one way to indicate dependent elements within a behavior.

The following design questions below can help to determine when to use nested policy expressions:

Are these assertions designed for the same policy subject? 

Do these assertions represent dependent behaviors?

If the answers are yes to both of these questions then leveraging nested policy expressions is something to consider. Keep in mind that a nested policy expression participates in the policy intersection algorithm. If a requester uses policy intersection to select a compatible policy alternative then the assertions in a nested policy expression play a first class role in the outcome. If there is a nested policy expression, an assertion description should declare it and enumerate the nested policy assertions that are allowed.

There is one caveat to watch out for: policy assertions with deeply nested policy can greatly increase the complexity of a policy and should be avoided when they are not needed.


----------------------------------------------------------------------------
<change to>
5.4.2 Nested Assertions
The framework provides the ability to "nest" policy assertions. For domains with a complex set of options, nesting provides one way to indicate dependent elements within a behavior. The granularity of assertions is determined by the authors and it is recommended that care be taken when defining nested policies to ensure that the options provided appropriately specify policy alternatives within a specific behavior. 

In particular, when assertion authors define nested assertions, it is important that the semantic of an empty policy element be defined. 
The following design questions below can help to determine when to use nested policy expressions:
	Are these assertions designed for the same policy subject? 
	Do these assertions represent dependent behaviors?
If the answers are yes to both of these questions then leveraging nested policy expressions is something to consider. Keep in mind that a nested policy expression participates in the policy intersection algorithm. If a requester uses policy intersection to select a compatible policy alternative then the assertions in a nested policy expression play a first class role in the outcome. If there is a nested policy expression, an assertion description should declare it and enumerate the nested policy assertions that are allowed. Additional information might be needed in the description to explain the relationship between the nested assertion semantics and the parent assertion.  Assertion authors should be aware that the meaning of a nested assertion is always evaluated in the context of its parent.  This can be illustrated by the WS-Addressing assertions.

<Policy>   		
<ExactlyOne>
    <Addressing>
	<Policy/> 	<!V1>
    </Addressing>	
   <Addressing>
	<Policy> 	<!V2>
              <AnonymousResponses />
         </Policy>
    </Addressing>	
    <Addressing>
	<Policy> 	<!V3>              
	    <NonAnonymousResponses />
         </Policy>
    </Addressing>
  </ExactlyOne>
</Policy>	

In the example above, the first alternative vocabulary (V1) indicates that  the full WS-Addressing spec is supported.   The second alternative vocabulary ( V2) indicates that another alternative is for WS-Addressing with AnonymousResponses ( to support intersection with those implementations that ONLY support AnonymousResponses and which would not intersect with the alternative expressed in V1).  And the third alternative vocabulary ( V3) indicates that another alternative is for WS-Addressing with NonAnonymousResponses ( to support intersection with those implementations that ONLY support NonAnonymousResponses and which would not intersect with the alternative expressed in V1 or V2).

There is one caveat to watch out for: policy assertions with deeply nested policy can greatly increase the complexity of a policy and should be avoided when they are not needed.