Re: LC124 - Support of evolution of messages described in Schema 1.0


Thx for the recap.

I am concerned about the informality of your evolution rules. XML Schema 
is an incredibly complex spec. My concern is that it is not obvious that 
there is always a unique way to throw away unexpected content in order to 
obtain a valid message. This concerns me because it could lead to 
interoperability problems, i.e. a C# client doing something different than 
a Java client.

As I pointed out, the V2S schema makes assumptions that the added elements 
are not part of a known schema. We need to nail down the restrictions.

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text:

Sent by:
07/15/2005 12:56 PM


LC124 - Support of evolution of messages described in Schema 1.0

Ahead of next week's F2F here's my best understanding of  the current 
of proposals and discussion for LC124.

** Description and Justification **

Original Proposal (Paul):

In essence, there is no way to describe the common and natural
evolution of an XML structure using XML Schema 1.0, eg.:







whereby a format may evolve remaining backwards compatible following
three simple rules:

                 - make additional items optional
                 - don't delete items
                 - don't change the meaning of existing items

** Proposed Text **

Latest evolution (Jonathan):

The "ignoreUnknown" property set to "true" denotes that the service 
accepts without faulting additional _unexpected items_ in messages sent to 
that service.  _Unexpected items_ are attributes and elements not defined 
by the schema for a particular element in the input message.  _Unexpected 
items_ may appear in any namespace including the targetNamespace of a 
known schema, as well as in a namespace for which no schema is currently 
known.  _Unexpected items_ includes the descendents of the item, such any 
child elements, attributes and content. 

Note: one mechanism for accomplishing this is to validate a message after 
content that is not known has been removed.  The unknown content may be 
identified by a W3C XML Schema processor.  The [validity] property in the 
Post Schema-Validation Infoset will contain a "notKnown" value if unknown 
content is found.

The same assertion, or a parallel one should denote that the service is 
liable to insert unexpected items in messages it emits which a client 
should accept.

resulting from text from DaveO:

and Paul:

** Proposed Syntax **

There is uniform agreement that a ignoreUnknown flag would be required to 
control this feature, true meaning ignoreUnknowns, false meaning strict 

Options for syntax:

** Discussion **

Berlin F2F, 1 June 2005, overview of issue:

Telcon 9 June 2005, agreed not to close with no action:

Telcon 16 June 2005, validate twice and IP:

W3C Workshop on XML Schema 1.0 User Experiences, 22 June 2005:
Slides (Paul):


Chairs' summary report:

Telcon 23 June 2005, feedback from workshop:

Telcon 30 June 2005, syntax, precedence of flag on types and endpoint: 

** Some Mailing List Concerns **

That unknowns might be ambiguous (Jonathan):
You have to be able to write a schema which describes the V2
and V1 messages, UPA actually helps here (Paul):

Lack of formal text to cite (Arthur):

Similar issues as with SOAP Encoding (Arthur):

But you can still validate (Paul):

psvi:notKnown != unknown (Arthur):
Explanation (Sandy Gao):

Problems with ignoreUnknows (soap Headers and body element) (Amy):

Attempt at a reply (Paul):

Evolution is a narrow use-case (Arthur, Umit and Pete Hendry (Cape))
various emails, refuted by Paul :-)


Received on Wednesday, 20 July 2005 05:06:38 UTC