[Bug 4270] Primer versioning example

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4270

           Summary: Primer versioning example
           Product: WS-Policy
           Version: PR
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Primer
        AssignedTo: fsasaki@w3.org
        ReportedBy: orchard@pacificspirit.com
         QAContact: public-ws-policy-qa@w3.org


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

Received on Monday, 22 January 2007 21:46:06 UTC