change summary for Section 5.3 and section 5.5

Section 5.3, Considerations when Modeling New Assertions
There are several subsections in section 5.3.
Each was restructured to have an introduction, a good practice, and where 
appropriate, an example.

The first section is 5.3.1 is the Minimal approach and the Good Practice 
is to start with a simple assertion and then extend with
nesting or parameters.  The examples given are Security Policy and 
Reliable Messaging Policy.

The next section 5.3.2,  is on Qnames and  XML Info set representation. In 
this section there are several Good Practices.
The first  is to use a unique  Qname and provide an XML outline and the 
example given is from Security Policy.
The second is to define clear semantics for the policy assertion, and 
there is no example for this currently.
The third is to provide an XML outline and schema and the example given is 
from Reliable Messaging.

Section 5.3.3, is on Self Describing Messages, The Good Practice in this 
section is a little long, but tries to characterize
what should and shouldn't be expressed by an assertion. The example given 
is also from Security Policy.

Section 5.3.4 provides guidance on assertions from a Single Domain. The 
Good Practice is to avoid duplication of assertions
and there is no example given for this section.

The other Good Practices I added to the Guidelines appear in Section 5.5.
This section deals with Ignorable Assertions and there are two good 
practices defined. Good practice for Ignorable behavior 
includes using the attribute to designate behaviors that can be ignored 
during intersection, and instructing authors to include the
attribute in the assertion XML outline when possible.

Both of these could use examples, but since this is new behavior, there 
aren't policies to reference.