RE: [xml-dev] [Summary] Backward and forward compatible schemas ... Re

["Dave Orchard" <orchard@pacificspirit.com>]

> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org] 
> Sent: Friday, August 24, 2007 8:32 AM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] [Summary] Backward and forward compatible 
> schemas ... Relax NG --> Yes ... XML Schema -->Yes
> 
> 
> Thanks everyone for your excellent comments!  
> 
> Special thanks to David Orchard.  David, I read your article. 
>  I now understand how to implement backward and forward 
> compatible schemas using XML Schema.  The technique you 
> illustrate is very powerful.

Not a problem!  And with Schema 1.1, it is much easier to do backward and forward compatible schemas..

> Notice that successive schema versions "added" new elements.  
> Is there a way for successive versions to remove elements and 
> still remain backward and forward compatible?
> 

It depends what you mean by "remove".  

If you mean remove and not accept, then the options depend upon the cardinality in V1.  If you mean remove the definition but still
accept, then in general the language can still be fully compatible.  An example of remove and still allow would be to replace an
element with a wildcard that allows that element.  As we've previously said, this is possible only in some specific cases in XSD 1.0
- such as an element in a non-targetnamespace being replaced by an any with namespace="##other" - and more generally allowable in
XSD 1.1.  The theory is that you've reduced the "defined text set" size but not the "accept text" set, which is forwards and
backwards compatible change.  See a formal model of compatibility at
http://www.xml.com/pub/a/2006/12/20/a-theory-of-compatible-versions.html and the TAG versioning finding terminology
(http://www.w3.org/2001/tag/doc/versioning) for more explanation of the terms and set theory.

Under remove and not accept, elements with maxOccurs greater than minOccurs can have maxOccurs reduced to the minOccurs and the
newer language is forwards compatible because an "newer" producer will then not produce the content up to the old maxOccurs.  In the
easy case, this means removing optional content is forwards compatible.  The newer language is not fully backwards compatible
because an "older" producer may produce the content with cardinality greater than the new "maxOccurs".  If the "older" producer only
produces content within the new maxOccurs, then the producer has effectively subsetted the language such that the language it is
using is backwards compatible.  This is one advantage of "partial understanding".  

It is not possible to reduce the maxOccurs less than the previous minOccurs (ie removing mandatory elements) and be forwards
compatible because older consumers will not accept the newer documents because there aren't enough of the element or backwards
compatible because newer consumers will not accept the older documents because there are too many of the element.  

In a more formal model, it is forwards incompatible because Defined Text set of the new language is smaller than the older languages
Defined Text Set (not enough) and it is backwards incompatible because the Defined Text set of the old language is larger than the
Accept Text Set (too many) of the newer language.   

Cheers,
Dave