Title: Ignorable Section should be parallel to Optional Section
Target: Guidelines

Description: The current section on ignorable should have comparable sections to the optional section.  

This proposal has 2 parts:
-------------------------------------------------------------------------------
Part 1 ---IGNORABLE SECTION CHANGES
------------------------------------------------------------------------------

<change from>

Policy assertions can be marked with an attribute to indicate that the assertion can be ignored by the interstection algorithm. Assertion Authors should consider whether the behavior represented by the Assertion they are defining can be ignored for the purposes of intersection, and indicate this in the definition of the assertion. The use of the ignorable attribute influences whether or not certain assertions are part of the compatability assessment between two alternatives. See [tbd] for details on the use of the ignorable attribute. 

5.5.1 Assertions and Ignorable Behavior
Best practice 14: Assertions Document Ignorable Behavior

An assertion description should use the wsp:Ignorable attribute to indicate that the behavior indicated by the QName may be ignored by policy intersection. 

5.5.2 XML Outline for Ignorable 
Best practice 15: Ignorable Attribute in XML

An assertion XML outline should allow for the use of the wsp:Ignorable attribute to indicate ignorable behavior. 



----------
<change to>
5 Designating Ignorable Behavior

5.5.1 Ignorable behavior in intersection
Ignorable behaviors represent behaviors that may be ignored by the intersection  algorithm. At a minimum, assertion authors need to document the semantics of the assertions [Best Practice 2] and included in that definition should be some  indication about any impact of the assertion behavior at intersection and  at runtime. 

When policy expression authors include assertions in service policies, some behaviors may be  marked by using wsp:Ignorable attribute with a value of "true". (In order to simplify reference to such assertions, we just use the phrase ignorable assertions in this section.)  It is recommended that assertion authors indicate this in the XML outline[Best Practice 7x].

During  intersection, there are two defined modes for processing, lax and strict.
Policy assertions marked with an attribute to indicate that the assertion can be ignored by the interstection algorithm are processed differently by algorithms in strict and lax mode [see Framework & Primer for details] . Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and indicate this in the definition of the assertion. The use of the ignorable attribute influences whether or not certain assertions are part of the compatability assessment between two alternatives. 

5.5. 2 Ignorable behavior at runtime
Ignorable behaviors indicate behavior at the time of intersection. At runtime, a party that indicated an ignorable behavior in its policy may engage the behavior that was marked ignorable for intersection. Assertion authors should indicate the semantic of the runtime behavior in the description of the assertion that allows the ignorable attribute.  

Policy intersection in strict mode will result in an alternative that consists only of assertions known to both parties.  Hence the runtime behavior is known to both.

Policy intersection in lax mode may result in alternatives with assertions that exist in one parties policy but not the other parties policy.  In the case where one party chooses to engage in runtime behavior with another party based on alternatives from a lax mode intersection algorithm,  the runtime behavior is out of scope of the policy framework. 
-------------------------------------------------------------------------------Part 2 ---OPTIONAL SECTION CHANGES
-------------------------------------------------------------------------------

<change last sentence in this section to include a reference to the XML outline section (5.3.2)>

Optional behavior in Compact authoring

An assertion author should clearly indicate in the assertion definition that it is possible to be optional and to allow the use of the wsp:Optional attribute in the XML definition[SEE SECTION 5.3.2]. 
------------------------------------------------------------------------
<delete>
-----------------------------------------------------------------------
Best practice 16: Assertion XML should allow use of wsp:Optional attribute

An assertion XML outline should allow the use of the wsp:Optional attribute to indicate optional behaviors.

To give a general example, the definition of assertion syntax for a hypothetical assertion such as SampleAssertion, should allow attribute extensibility as part of the XML definition, allowing the wsp:Optional attribute to be used: 

Example 5-8. Use of @any for attribute extensibility

/samplePrefix:SampleAssertion/@any
This is an extensibility mechanism to allow additional attributes to be added to the element, including wsp:Optional.
				
The portion of the assertion definition that describes policy subjects and assertion attachment should indicate that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.

Best practice 17: Assertion description should explicitly indicate that wsp:Optional is allowed.

An assertion description should use the wsp:Optional attribute to indicate that the behavior indicated by the QName is optional for the associated policy subject.

Continuing the example with the hypothetical SampleAssertion, the section on Assertion Attachment should include discussion of optionality. 

Example 5-9. Assertion Attachment text mentions optionality for policy assertion subjects

The SampleAssertion policy assertion indicates behavior over all messages in a binding, so it has an Endpoint Policy Subject and must be attached to a wsdl:binding or wsdl:port.  The assertion may be optional when attached to these subjects, allowing use of wsp:Optional.