OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange

Thanks Derek.  Yes, you are correct, my comments apply not only to XML
Schema, but also to Relax NG and DTD (i.e. to any grammar-based schema

Moments ago I saw the following message.  It summarizes perfectly the
point I am trying to make.

Someone wrote:

> If an application is implemented to understand a v2 schema, it is
> considered backward compatible if it can successfully process XML
> documents that are created from either the v2 schema or from the v1

I responded:

Not true.  The application *may* be able to process v1 XML documents.
The only thing that a backward compatible schema guarantees is that it
can *validate* v1 XML documents.  Backward-compatibility in no way
guarantees that applications can *process* v1 XML documents.  


-----Original Message-----
From: derek denny-brown [mailto:zuligag@gmail.com] 
Sent: Wednesday, December 26, 2007 12:30 PM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Caution using XML Schema backward- or
forward-compatibility as a versioning strategy for data exchange

Your title and summary indicate that you believe that these
limitations are specific to XML Schema, but nothing I saw in your
examples ties the issues you highlight to XML Schema.  Fundamentally,
creating a forward compatible schema amounts to attempting to predict
the future.  Other schema languages for XML may provide stronger
capabilities, but ultimately you face the same problem.

XML is a means of communicating information.  Handling versioning of
information exchange is a problem that has been with us as long as
humans have had communication.  Computers and automated processing
exacerbate the problem because of their lack of flexibility.  A
teenager can adjust to the language of Herman Melville, but skip a
single semicolon and your C compiler falls on the floor.  Versioning
schema for XML is not significantly different than versioning a code
library's API.  Both require careful thought and understanding of the
customers, scenarios, and tradeoffs.  Both eventually require breaking
changes, and even a complete rewrite to cleanly incorporate certain

XML Schema is just one way to express constraints on what kind of XML
is deemed correct.  Throw away XML Schema and imagine near-infinite
freedom to define the rules that validate an instance.  As bad as XML
Schema (1.0) is at handling versioning, I argue that you will find
still find the same core versioning issues.


On Dec 26, 2007 8:09 AM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
> Designing XML Schemas to be backward- or forward-compatible is a
> popular approach to data versioning.
> I think some cautions need to be raised with versioning strategies
> based on XML Schema backward- or forward-compatibility.
> Below I list the cautions.  Do you agree with these cautions?  Are
> there cautions I have missed?
> Consider deploying a web service.  Assume the web service has no
> knowledge of who its clients are, or how clients use the data they
> retrieve from the web service.
> The web service uses an XML Schema to describe the syntax of the data
> it exchanges with clients.
> The web service uses the following data versioning strategy:
>     Each new version of the XML Schema is designed to be
> forward-compatible.
> Thus a client with an old XML Schema can validate an XML instance
> document generated by the web service using a new XML Schema.
> Given the scenario described, what cautions should be raised on the
> of forward-compatible XML Schemas as a versioning strategy for data
> exchange?"
> A versioning strategy based on backward-compatibility has the same
> cautions. I will not explicitly mention backward-compatibility in the
> rest of this message, but bear in mind that the comments apply to it
> well.
> Consider a client application implemented to process version 1 data
> from the web service.
> Suppose the web service changes its XML Schema, in a
> fashion.  Will the client application be able to process the new
> (version 2) data?
> Since the XML Schema is forward-compatible the application will be
> to "validate" the new data.
> But it is not necessarily the case that the application will be able
> "process" the new data.
> Example #1: Suppose in the first version of the XML Schema this
> element:
>     <distance>100</distance>
> means "distance from center of town."  Accordingly, the client's
> application does calculations based on that meaning.
> In the version 2 data the syntax is changed in a forward-compatible
> fashion.  In addition, the semantics of the <distance> element is
> changed to "distance from town line."
> The client application will be able to validate the version 2 data,
> the calculations will be incorrect.
> Example #2: If the version 1 XML Schema defaults the <distance> units
> to miles and the version 2 XML Schema defaults the <distance> units
> kilometers then the data will validate but the client's application
> will make incorrect calculations.
> Lesson Learned #1: Data may change syntactically in such a way that
> validation is not impacted, and yet applications break.
> Lesson Learned #2: Just because an application can validate data
> doesn't mean it can process the data.
> Lesson Learned #3: Forward-compatible XML Schemas yield increased
> validation but not necessarily increased application processing.
> Lesson Learned #4: There is no necessary correlation between the
> ability to validate data and the ability to process data.
> Lesson Learned #5: A versioning strategy must take into account:
>     1. Syntactic changes
>     2. Relationship changes
>     3. Semantic changes
> Designing a new version of an XML Schema to be forward-compatible
> an old version necessitates that the only changes made in the new
> version are "subset" changes, such as:
>     - constrain an element's or attribute's datatype
>     - reduce the number of occurrences of an element
>     - eliminate an optional element or attribute
>     - remove an element from a choice
> This is very restrictive.  And to what avail?  Answer: to enable
> validation of new XML instance documents against an old XML Schema.
> But as described above, just because data can be validated doesn't
> it can be processed.
> Further, for the scenario we have been considering, the web service
> no idea about how its data will be processed by clients.
> there is no evidence that the additional validation provided by
> forward-compatible XML Schemas will help clients.
> Lesson Learned #6: A versioning strategy based on forward-compatible
> XML Schemas imposes limitations on the types of changes; those
> limitations may not be consistent with the actual changes needed by
> application.
> Lesson Learned #7: Version data based on data requirements rather
> technology limitations.
> 1. Do you agree with the cautions listed above?
> 2. Are there other cautions?
> 3. Do you agree with the Lessons Learned?
> 4. Given the scenario described above, is it wise to base a
> strategy on forward-compatible XML Schemas?
> /Roger
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS