This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4270 - Primer versioning example
Summary: Primer versioning example
Alias: None
Product: WS-Policy
Classification: Unclassified
Component: Primer (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Felix Sasaki
QA Contact: Web Services Policy WG QA List
Depends on:
Reported: 2007-01-22 21:46 UTC by David Orchard
Modified: 2007-01-31 17:59 UTC (History)
0 users

See Also:


Description David Orchard 2007-01-22 21:46:01 UTC
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.


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

    <All> <!-- - - - - - - - - - - - - - - - NEW Policy Alternative -->
      <sp:AsymmetricBinding>...</sp: AsymmetricBinding >

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
Comment 1 Christopher Ferris 2007-01-31 17:59:49 UTC
RESOLUTION: adopt proposal herein, with "hypothetical" adjective added to all occurances of 'ignorable EndOfLife'.

[12:58] Fabian: resolution: 4270 with message 220 and similar changes to rest of document adopted
[12:59] cferris: rrsagent, where am i?
[12:59] RRSAgent: See