There is a versioning use of ignorable that may be appropriate for the Primer document.  In many real systems, systems are compatibly versioned by doing "side-by-side" versioning followed by EOL(EndOfLife)ing the older version.  Side-by-side deploymement supported by the alternatives are described in 3.8 but there may be extra information conveyed wrt the EOL using the ignorable attribute.  

I propose the following text for the Primer, section 3.8.1 at the end of 3.8.

Ignorable

One potential use of the wsp:Ignorable attribute is to mark versioning related information.  One scenario is that a service will support a particular version of a service until a certain point in time.  After that time, the service will not be supported.  The expiry date and time of the service would be a domain expression, but it could be marked as
ignorable.   When an alternative does have an expiry, it is usually
useful to convey this information to help smooth the versioning process.

Contoso could specify that the older policy alternative will expire at a certain point in time using a contoso specific expiry assertion.  The example below shows Contoso version 2 policy expression with ignorable EndOfLife Assertion.

Example 3-13. Contoso's Version 2 Policy Expression with ignorable EndOfLife Assertion

<Policy>
  <ExactlyOne>
    <All>
      <contoso:EndOfLife
wsp:Ignorable="true">Mar-31-2008</contoso:EndOfLife>
      <wsap:UsingAddressing/>
     <sp:TransportBinding>...</sp:TransportBinding>
    </All>
    <All> <!-- - - - - - - - - - - - - - - - NEW Policy Alternative -->
      <contoso:EndOfLife
wsp:Ignorable="true">Mar-31-2999</contoso:EndOfLife>
      <wsap:UsingAddressing/>
      <sp:AsymmetricBinding>...</sp: AsymmetricBinding >
    </All>
  </ExactlyOne>
</Policy>

In this variant of the versioning scenario, the use of ignorable allows versioning related information to be conveyed and used where understood.

In a scnario such as this, where an assertion type is used for ignorable information, the use of strict or lax mode and presence or absence of the assertion type in the first version are important decisions.  If Contoso wishes clients to always be able to ignore the assertion, particularly those using strict intersection, the first policy alternative offered should contain the policy assertion type.  If Contoso adds the policy assertion type to a subsequent alternative, then requestors using strict mode will not understand the assertion type and the alternative with the ignorable information will not be compatible with the older version of the alternative as per the intersection rules.  Thus the widest possible alternative compatibility will be to have the ignorable policy assertion type in the very first version of the alternative.  The second alternative shown also contains the EOL policy assertion type.  Because the actual value is not known, a value that is roughly infinitely in the future is used.  A subsequent policy alternative could refine the value.   

The advantage of adding the EOL information is that some clients will have a machine processable way of knowing when the alternative will no longer be supported.  Without this information, the information must be conveyed in some other way or it will not be conveyed at all.  This can usefully smooth the transition between versions.  

Recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action07