ACTION-152 Review 4.4.8 with respect to the addition of the ignorable attribute

I have reviewed the Primer wrt the addition of the ignorable attribute.


In general, I think that versioning of the policy language is well
supported as described.  I don't see any use cases for marking a new
construct in WS-Policy as "ignorable" because the alternative model
provides the necessary functionality.  I looked at all the sample
versioning scenario where a new construct is created and none of them
seemed well-served by being marked with ignorable.  For example, the
wsp16:Choice construct seems better marked with optional.  Same with the
binding.

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 -->
      <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.


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.

Cheers,
Dave

Received on Tuesday, 19 December 2006 22:44:28 UTC