Re: [xml-dev] Caution using XML Schema backward- or forward-compatibilit

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

Well, I think changing the semantics of elements falls outside the
normal understanding of compatibility.

Cheers,
Bryan Rasmussen

On Dec 26, 2007 8:01 PM, Costello, Roger L. <costello@mitre.org> wrote:
>
>
> 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
> language).
>
> 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
> schema
>
> 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.
>
> /Roger
>
>
> -----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
> changes.
>
> 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.
>
> -derek
>
>
> 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?
> >
> >
> > SCENARIO
> >
> > 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.
> >
> >
> > ISSUE
> >
> > Given the scenario described, what cautions should be raised on the
> use
> > of forward-compatible XML Schemas as a versioning strategy for data
> > exchange?"
> >
> >
> > NOTE
> >
> > 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
> as
> > well.
> >
> >
> > CAUTION #1: JUST BECAUSE A CLIENT CAN VALIDATE THE DATA IT RETRIEVES
> > DOESN'T MEAN IT CAN PROCESS THE DATA
> >
> > Consider a client application implemented to process version 1 data
> > from the web service.
> >
> > Suppose the web service changes its XML Schema, in a
> forward-compatible
> > 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
> able
> > to "validate" the new data.
> >
> > But it is not necessarily the case that the application will be able
> to
> > "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,
> but
> > 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
> to
> > 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
> >
> >
> > CAUTION #2: FORWARD-COMPATIBLE CHANGES ARE BASED ON TECHNOLOGY
> > LIMITATIONS RATHER THAN APPLICATION REQUIREMENTS
> >
> > Designing a new version of an XML Schema to be forward-compatible
> with
> > 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
> mean
> > it can be processed.
> >
> > Further, for the scenario we have been considering, the web service
> has
> > no idea about how its data will be processed by clients.
> Accordingly,
> > 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
> an
> > application.
> >
> > Lesson Learned #7: Version data based on data requirements rather
> than
> > technology limitations.
> >
> >
> > QUESTIONS
> >
> > 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
> versioning
> > 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
> >
> >
>
> _______________________________________________________________________
>
> 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
>
>