Cart
[Home] [By Thread] [By Date] [Recent Entries]
> -----Original Message----- > From: Costello, Roger L. [mailto:costello@m...] > Sent: Friday, August 24, 2007 8:32 AM > To: xml-dev@l... > Subject: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
