Proposal for LC124

Following our time constrained discussion at the Berlin F2F
on LC124, and ahead of tomorrow's telcon, here is a concrete 
proposal to enable support for evolution of messages 
described using XML Schema 1.0 in WSDL 2.0.


There are three common uses for an XML Schema description in WSDL:

1) as a description of the required content of messages 
    to be constructed by a sender

2) as a description of the message contents 
   available for a receiver to process

3) as a means of validating the format of a message, 
    possibly by a third party observing the message exchange.

In our experience (1) and (2) represent the core usage of XML
Schema in WSDL.  Strict validation of messages being something
of an edge-case, but an important one we should not preclude.

As discussed ad-nausea in this Working Group and elsewhere, there is 
a natural expectation amongst Web service developers when using a 
self-describing format, such as XML that it should be possible for a sender 
to pass more data than is contained in the description and for the receiver 
to simply ignore unknown items. This is commonly known as the
"mustIgnore rule", enables "passive versioning", and is the main
reason behind the successful evolution of the Web [1].

Those wishing to communicate a break in compatibility of a message
simply have to change the namespace of the message contents.

XML Schema 1.0 cannot preclude a Web Services agent from
following the mustIgnore rule when constructing or processing
messages. However such modified messages fail validation against
an unmodified schema description, strict validation being the primary
purpose of the the XML Schema specification.


The proposal is to provide support for the 'mustIgnore' rule in
WSDL 2.0 when using XML Schema 1.0. That is a sender MAY arbitrarily
send more data than is described by an XML Schema 1.0.
A receiver MUST ignore additional, undexpected content when processing a 

When validating a WSDL processor must first remove additional content
before applying standard XML Schema 1.0 processing. There is no need
to specify how this removal should be achieved, however one possible
implementation is to use Henry Thompson's 'validate twice' technique [2]
Other techniques for this removal may exist, or be developed and therefore
should not be precluded by our specification.

If required, it should be possible for us to cite Henry's
text as an example in an appendix, primer or as separate note.

Other type systems may already support more open content models or
have very different processing properties, therefore this proposal is 
targeted solely at XML Schema 1.0 descriptions.

Option 1) make mustIgnore mandatory

     No changes to our syntax. Descriptions in
     XML Schema are open to additional content by default.

Option 2) make mustIgnore optional

In the following, mustIgnore processing is under the 
control of a wsdlx:mustIgnore attribute which by default may 
be 'true' (mustIgnore on) or 'false' (follow strict validation 
when sending and processing messages):

Option 2a) extension attribute on the xs:schema element

      <xs:schema wsdlx:mustIgnore='true' ...

    The mutIgnore processing applies to messages which reference
    a global element declaration (GED) within the flagged schema.

Option 2b) extension attribute on the GED

	<xs:element wsdlx:mustIgnore='true' ...

    The flag applies to messages which directly reference the
    element as their global element declaration (GED).

In either case the granularity of the mustIgnore processing is
placed on the entire message. i.e. there are no rules for turning
mustIgnore processing on or off on a per-element or type or individual
schema basis inside a single message. Of course nothing precludes
other specifications from providing such fine-grained functionality 
in the future.

I decided against using xs:annotation element extensibility
for simplicity.

A Position

It is BT's position is that the Status Quo represents an
unacceptable state of affairs for a Web services description

Option 1 is our strong preference, but one of the optional
flags would be acceptable. However optionality could lead to further
issues for WSDL and may be subject to mixed support or profiling.


Last Call Issue 124:

Abstract proposal:

[1] Timbl on Evolution:

[2] Henry Thompson's validate twice:

An online demonstration of Validate Twice using an XML pipline:

Received on Wednesday, 8 June 2005 17:54:01 UTC