Action-28: daveo look at adding/developing versioning policy material to primer/guide

The following is a partial and may be full fullment of the action item.
I have produced material for Versioning of the Policy Language for the
Primer.  I have not produced materal for assertion versioning as my
understanding is that Umit and Maryann are working on that.  Thanks to
Asir for multiple detailed reviews.  

Cheers,
Dave

For the Primer..

4.4.8 Versioning Policy Language
Over time, the Policy WG or third parties can version or extend the
Policy Language with new or modified constructs.  These constructs may
be compatible or incompatible with previous versions.  Some of the
possible new constructs that have been mentioned previously are: new
operators, operator cardinality, policy identification, compact syntax,
Policy Inclusion, security, referencing, attachment points, alternative
priority, effective dating, negotiation.    

WS-Policy provides extensibility points on 6 elements with a combination
of attribute and/or element extensibility.  The possible extensibility
points with their current extensibility - including some outstanding
issues related to extensibility - are:

Policy: element from ##other namespace and any attribute
PolicyReference: any attribute and a proposal to add any element
ExactlyOne, All: element from ##other namespace, no attribute
extensibility
PolicyAttachment:  element from ##other namespace and any attribute
AppliesTo: any element and any attribute

Policy Framework
----------------
WS-Policy Framework 1.5 specifies that any element that is not known
inside a Policy, ExactlyOne or All will be treated as an assertion.  The
default value for wsp:Optional="false", which means after normalization
it will be inside an ExactlyOne/All operator.  

Let us show an example with a hypothetical new operator that is a Choice
with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new
namespace.  We use the wsp16 prefix to indicate a hypothetical Policy
Language 1.6 that is intended to be compatible with Policy Language 1.5:

Example . Policy containing 1.5 and 1.6 Policies.

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
      ...
    </wsp16:Choice>
    <wsp:All>
       ...
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

The normalization rule for wsp:Optional="false" would be applied to the
wsp16:Choice, yielding the following expression:

Example . Normalized Policy containing 1.5 and 1.6 Policies.

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:ExactlyOne>
      <wsp:All>
         <wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
          ...
        </wsp16:Choice>
      </wsp:All>
    </wsp:ExactlyOne>
    <wsp:All>
       ...
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Alternatively, the wsp:Optional could be set to "true" on the choice, as
in:

<wsp:Policy>
  <wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"
wsp:Optional="true">
      ...
  </wsp16:Choice>
</wsp:Policy>

The normalized form will be:
<wsp:Policy>
  <wsp:ExactlyOne>
     <wsp:All>
         <wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
          ...
        </wsp16:Choice>
      </wsp:All>
     <wsp:All/>
  </wsp:ExactlyOne>
</wsp:Policy>

Because the wsp16:Choice alternative isn't understand in either
normalized form, it will not be chosen as one of the alternatives and
will effectively be ignored.  Policy intersection may be more difficult
with such compatible extensions.  For example, the previous will "look"
like it has a wsp16:Choice typed assertion.  To determine intersection
with a Policy that does not have the wsp16:Choice type assertion, domain
specific processing would have to be done.  However, there is an
alternative that does not have the wsp16:Choice, so intersection would
yield the expecteded result.

Note: it is not possible to add new names to the existing namespace,
such as: 

Example . Policy containing 1.5 and 1.6 Policies all in the 1.5
namespace.

<wsp:Policy>
  <wsp:ExactlyOne>
    <wsp:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
      ...
    </wsp:Choice>
    <wsp:All>
       ...
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Notice that using a new namespace can result in backwards and forwards
compatibility if normalization results in an optional alternative. 

Best practice: insert new elements in an optional alternative or mark
with wsp:Optional="true". 

Incompatible versions of the Policy language may be indicated by a new
namespace name for at least the new and/or incompatible elements or
attributes.  Imagine that the Choice operator is required by a future
version of Policy, then there will be a new namespace for the Policy
element.  We use the wsp20 prefix to indicate a hypothetical Policy
Language 2.0 that is intended to be incompatible with Policy Language
1.5:

Example . Policy containing 1.5 and 2.0 (incompatible with 1.5)
Policies.

<wsp20:Policy>
  <wsp20:ExactlyOne>
    <wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
      ...
    </wsp20:Choice>
    ...
  </wsp20:ExactlyOne>
</wsp20:Policy>

The new Policy operator could be embedded inside an existing Policy
element:

Example . Policy containing 2.0 (incompatible with 1.5) Policies
embedded in wsp 1.5 Policy.

<wsp:Policy>
    <wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
      ...
    </wsp20:Choice>
    ...
</wsp20:Policy>

This will be treated as an Assertion for normalization and intersection
computation.  This will result in only one alternative that requires the
wsp20:Choice, the intended behaviour for incompatible changes.

Best practice: use a new namespace for new incompatible construct and
insert inside either: new Policy element OR existing All for future
incompatible policy extensions.

We can also imagine that a future version of WS-Policy would support the
current operators in the existing namespace, such as:

<wsp20:Policy>
  <wsp:ExactlyOne>
    <wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
      ...
    </wsp20:Choice>
    ...
  </wsp:ExactlyOne>
</wsp20:Policy>

However, it is difficult to predict whether this functionality would be
useful.  The future version of WS-Policy doesn't appear to be precluded
from doing this.

Policy Attachment
-----------------
Policy attachment provides WSDL 1.1 and UDDI attachment points.  It
appears that exchange of Policy will be in the context of WSDL or UDDI.
WRT WSDL, the policy model is an extension of the WSDL definition.  As
such, it is likely that future versions of Policy will be exchanged as
multiple Policy expressions within a WSDL.  One alternative is that
there would be a separate WSDL for each version of Policy.  The problem
of how to specify and query for compound documents is very difficult, so
it is more likely that each version of Policy will be exchanged within a
WSDL.  

We show an example of a new version of policy that allows Qname
reference to Policies in the PolicyReference:

Example . WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy
References.

<wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
       <wsoap12:binding style="document"
          transport="http://schemas.xmlsoap.org/soap/http" />
	<wsp:Policy>
	  <wsp:ExactlyOne>
		<wsp:All>
	       	<wsp:PolicyReference URI="#RmPolicy"
wsdl11:required="true" />
      	      <wsp:PolicyReference URI="#X509EndpointPolicy"
wsdl11:required="true" />
		</wsp:All>
		<wsp:All>
	       	<wsp:PolicyReferenceByQName ref="rmp:RMAssertion"
wsdl11:required="true" />
      	      <wsp:PolicyReferenceByQName ref="sp:AsymmetricBinding"
wsdl11:required="true" />
		</wsp:All>
	 </wsp:ExactlyOne>
	</wsp:Policy>
       <wsdl11:operation name="GetLastTradePrice" > ....

The PolicyReference is attribute extensible.  One example of an addition
is a list of backup URIs for the policyReference:

Example . WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy
References.

<wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
       <wsoap12:binding style="document"
          transport="http://schemas.xmlsoap.org/soap/http" />
	<wsp:Policy>
	  <wsp:ExactlyOne>
		<wsp:All>
	       	<wsp:PolicyReference URI="" wsp16:alternateURIs="URI*"
wsdl11:required="true" />
      	      <wsp:PolicyReference URI="" wsp16:alternateURIs="URI*"
wsdl11:required="true" />
		</wsp:All>
	 </wsp:ExactlyOne>
	</wsp:Policy>
       <wsdl11:operation name="GetLastTradePrice" > ....

The policy framework specification says that any unknown attributes are
ignored.  Policy 1.5 processor will not understand the
wsp16:alternateURI attribute, it will be ignored.  A Policy 1.6
processor will understand the alternate URIs so it won't be ignored.

PolicyAttachment and AppliesTo also have extensibility points.  We
choose not to illustrate these at this time.

Cheers,
Dave

Received on Tuesday, 29 August 2006 18:41:26 UTC