DTD versioning

[Per-Ake Ling]

> From: "John Wilson" <tug at wilson.co.uk>
...[snip]

Although you seem mainly interested in using XML to communicate information
between programs, the problem you outline has been very relevant for
the SGML community, dealing with documents.

> 1/ To have a set of rules that specifies what changes or additions I can
> make to a DTD without breaking the original DTD(for example, adding an
> attribute or a default value to an existing attribute) and to have an
> automated way of checking that I've applied these rules.
> 
When we upgrade DTDs we do adhere to a certain set of rules, unfortunately
we do not have automated support but do the checking manually. As far as I
know there is no tools that specifically does this kind of job, but using
e.g. the DTD reports in psgml helps a lot.

> 2/ A way of specifying that the new DTD extends the old.
> 
We always put a product id and a revision in the public identifier for
the DTD. If the new DTD is strictly upwards compatible as in (1) above,
we only change the revision, else we assign a new product id. The criteria
for only changing the version number is that all old documenst can be
parsed with the new DTD without any errors. Another way of recording this
info is using major/minor numbers on the version to signal compatible
or incompatible changes.

> 3/ A Relational database view type mechanism that gives a set of simple
> mechanical transformations that turns the data which corresponds to one DTD
> to another.
> 
Everytime we create a new DTD, we also create a filter for converting
old documents to the new DTD by using an SP-based toolkit. In the trivial
case of strictly upwards compatible changes, the filter is simply
changing the public id for the external subset.

> In case 1/ the new DTD would just say that it is a valid superset of the old
> DTD, in case 2/ the DTD new DTD would specify the old and just contain the
> changes and additions, in case 3/ the DTD would refer to the view to be
> applied to transform the data to a form which is defined by the old DTD.
> 
> I would expect the XML parser to serve up the data  as described by the old
> DTD and that it (the parser) would suppress attributes, apply
> transformations, etc so that the data would appear in this form.
> 
We do the opposite, the tools that read the data are updated and then the
filters consistently serve up the data in the new form, irrespective of
its 'real' version.

> I suspect that I can do some or all these things with XSL, but that's really
> hitting a small problem with a very big hammer.

I consider this problem to be the other way around, using XSL would be
using a very small hammer for a very large nail.

In general, the DTD identification and versioning is very complex,
especially since the DTD that is valid in a particular document does not
really have an id since it is the sum of the internal and external
subsets and could very well be unique for every document (although
unlikely).

Probably the solution lies with architectural forms, which although
limited are quite adequate for many real-world problems. Eliot Kimber
has argued for using AFs to control your data in a safe but extensible
way, and I believe that is the only safe standard way that is currently
reasonable to implement. (SP already has support for AF).

Regards,
Per-Åke
--
Per-Åke Ling	(note: Per-&Aring;ke, transliteration Per-Ake)
email:	Per-Ake.Ling at uab.ericsson.se	phone:  +46  8 727 5674
Ericsson Utvecklings AB			mobile: +46 70 790 2446
AXE Research and Development		fax:	+46  8 727 3463

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)