Versioning -- XML Schema WG state of play

The first thing to say is that as yet, the XML Schema WG has no
specific position on versioning.  However, we have already engaged
in extensive discussion, and it will probably be helpful to understand
where (at least in my opinion) that discussion is heading.

After several months of discussion, Michael Sperberg-McQueen captured
many WG thoughts in [1].  Noah Mendelsohn has posted a much refined
note that the Schema WG has been using as a discussion guide [2], which
I believe he has reposted to the TAG list.  IMO [1] is useful as an 
issues guide, [2] is a fledgling architecture.  

I am not proposing to speak for Noah, but I don't think there are many
substantive differences in what I'm about to say and what is in his 
document.

I have long believed that the best way to solve the versioning problem is
to restore some of the "open content model machinery" that existed in SOX
and XDR into XML Schema, so that the content models people write can 
support forward compatible extensions (new instance documents, old code)
in a way that's natural and not contrived.

Honestly, I don't see how this can >not< be Schema's problem.

Versioning, at its most basic, is about two things.  The separation of
these two things is more-or-less what Noah talks about in "separation
of concerns".  

1) Forward compatibility at runtime

   Making it simpler to allow applications built around an older schema 
   (authored months or years ago) not to barf when an instance document 
   based on v2 shows up to be processed by an application.  Note that
   in this case the application has no access to (nor hope of accessing)
   a v2 schema.  It will have to make do with what it has.  We propose
   to accomplish this simplification with some changes to the how a schema
   controls content models.  (N.B. some WG members would say these changes
   reflect the way schemas should work anyway, regardless of whether we
   support versioning or not.)

2) Authoring concerns and logistics
   
   Only certain kinds of changes can be allowed.  We need possible
   syntax extensions and tools that:
   a) make it easy for a schema author to introduce legal changes
      (e.g. create a v2 from a v1 schema).
   b) provide content model tests that assure that two schemas are 
      "version compatible".  These tests need only be run at
      schema authoring time.
   c) provide certain kinds of maintenance utilities (TBD).
   d) create some way for schemas to identify themselves as being
      part of a versioning lineage.

Note that issues in #2 are 1) essentially orthogonal to one another
and 2) if implemented imaginatively might have no impact on runtime 
processors.

So far, we have deemed backward compatibility to be relatively trivial
(i.e. new applications >ought< to be able to know about old schemas
and documents).

The above is a gross simplification, but hopefully is useful to understand
the state of the discussions within the XML Schema WG on the subject.  I
have not given any details of the technical discussion for #1.  That discussion
includes PSVI issues and the like.

Best regards,
David Ezell
[1] http://lists.w3.org/Archives/Public/www-tag/2004Aug/0010.html
[2] http://www.w3.org/XML/2004/02/xsdv.html

Received on Tuesday, 10 August 2004 17:46:47 UTC