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

Hi Dave,

As we discussed on a previous working group call we think it is too early to make a solid recommendation in the Primer that expiry information get added to policy alternatives in the form of an EndOfLife assertion.  There are technical issues with the assertion that are not addressed.  What is the form of the assertion?  How is the assertion intersected?  If a provider adds the EndOfLife assertion, won't this break clients that are using strict mode intersection?

We think the idea of adding expiry information to policy alternatives is a compelling use of the policy framework, but at this point this proposal extends beyond providing an introduction to the Policy Framework and Attachment specs.  We recommend against adding this text.

Daniel Roth

-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of David Orchard
Sent: Tuesday, December 19, 2006 2:43 PM
To: public-ws-policy@w3.org
Subject: 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 Wednesday, 17 January 2007 16:30:52 UTC