- From: David Ezell <David_E3@VERIFONE.com>
- Date: Tue, 10 Aug 2004 13:48:11 -0400
- To: <www-tag@w3.org>
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