Title: Reorganize guidance on XML Info Set representation
Target: Guidelines

Description: There was another Action Item (305), which referred to making the sections on "ignorable XML" and "optional XML" info sets be parallel, but as I looked at the document as a whole, I think its better to reorganize the original section (5.3.2) and add two sub-bullets here for illustration of the two defined attributes, ignorable, and optional. 


Proposal: this proposal has two parts:

part 1 --
------------------------------------------------------------------------------------------------------------------
<change from > 
The syntax of an assertion can be represented using an XML outline (plus an XML schema document). If the assertion has a nested policy expression then the assertion XML outline can enumerate the nested assertions that are allowed. An example is the following: 
 <sp:IssuedToken sp:IncludeToken="xs:anyURI"? ... >
  <sp:Issuer> wsa:EndpointReferenceType</sp:Issuer>?
  <sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? >
    ...
  </sp:RequestSecurityTokenTemplate >
  <wsp:Policy >
    <sp:RequireDerivedKeys /> ?
    <sp:RequireExternalReference /> ?
    <sp:RequireInternalReference /> ?
    ...
  </wsp:Policy> ?
  ...
</sp:IssuedToken>
 
------------------------------------------------------------------------------------------------------------------
<change to > 
Outlines can also express nesting of assertions. 
In the example above,  the assertion, Delivery Assurance, has a nested policy expression.

------------------------------------------------------------------------------------------------------------------
part 2 --
------------------------------------------------------------------------------------------------------------------
<add>
To give a general example of adding attribute support, we first highlight that the WS-Policy Framework indicates [Section 3.1]:
The XML Infoset of a policy assertion MAY contain a non-empty [attributes] property and/or a non-empty [children] property. Such properties, excluding the Attribute and Element Information Items from the WS-Policy language XML namespace name are policy assertion parameters and MAY be used to parameterize the behavior indicated by the assertion.
An example of how the definition of assertion syntax for a hypothetical assertion such as SampleAssertion, would allow attribute extensibility as part of the XML definition is given below.
 
/samplePrefix:SampleAssertion/@any
This is an extensibility mechanism to allow additional attributes to be added to the element, including wsp:Optional.
				
The XML outline or the  assertion definition can  indicate that attributes ( wsp:Optional or wsp:Ignorable) can be used to indicate that the behavior is optional or ignorable for the policy subject.

Best practice 7x: Assertion XML outline can indicate use of wsp:Optional attribute
An assertion XML outline can indicate the use of the wsp:Optional attribute to indicate optional behaviors.
When an XML outline is included  in an assertion description, it is possible to indicate the use of the wsp:Optional attribute in the XML outline. The example given for reliable exchange above, indicates the use of optional on the RMAsertion.
 
Best practice 7x: Assertion XML outline can indicate use of wsp:Ignorable attribute
An assertion XML outline can indicate the use of the wsp:Ignorable attribute to indicate ignorable behaviors for intersection.
When an XML outline is included  in an assertion description, it is possible to indicate the use of the wsp:Ignorable attribute in the XML outline.
[need an example here]