RE: Updated versioning strategies doc [XMLVersioning-41 ISSUE-41]

Dan Connolly:

| On Thu, 2007-09-20 at 16:16 -0700, David Orchard wrote:
| > - updated the introduction to hit the 3 main messages right up front
| > 
| http://www.w3.org/2001/tag/doc/versioning-compatibility-strate
gies-20070920.html
|  
| 
| Dave and I talked over this new material. I can now "see the forest
| for the trees" better as a result. This is the bit with
| the 3 main messages:
| 
| [[
| This finding describes general problems and techniques in evolving
| systems in compatible ways. These techniques are designed to allow
| compatible changes. A number of design patterns and rules are 
| discussed
| with a focus towards enabling versioning. There are a few crucial good
| practices that enable forwards compatible versioning from 
| version 1 of a
| language.
| 
|   The first is to specify the language is extensible.
| 
|   The second is to specify that any text of the language with
|   extensions can be treated as if the extensions were not present.
| 
|   The third is to specify an algorithm for how a text of the
|   language with a version identifier that is unknown can be treated
|   as if the version identifier was known.
| ]]

I'd suggest:

The fourth is a way to overrule the second.

It is mentioned later in the doc in some sections, but I believe it's pretty
important. In Healthcare, where I work, I would never advise the use of [second]
without [fourth]. Some information in extentions may be crucial to patient
survival, so "ignore unknown" without overrule is not an option. I guess for
many B2B contexts the same applies, in general any context which is constrained
by legal obligations between the parties exchanging information.

I'd also suggest to put something like this in a Good Practice: If extensions
are expected which may not be ignored, a language should provide a mechanism to
indicate this.

Note: just assigning a new (major) version identifiers for incompatible changes
does not work well enough, for it's possible to have an optional element in an
extension which must be understood when present. Using a new major version would
then mean receivers would have to reject any message even when the optional
element is not present.

Regards,

Marc de Graauw

http://www.marcdegraauw.com

Received on Friday, 5 October 2007 09:27:28 UTC