Extending DTDs for Backward Compatibility

[Joe Lapp]

I need to create DTDs that are extensible.  An application knowing the
semantics behind an old DTD may be handed an XML document written with an
extended DTD.  The old application should be able to function with the
extended document by ignoring the extensions.  I need advice on the best
way to go about creating the initial DTD (and subsequent DTDs, should their
designs also be a factor).

There are different ways in which I might want to extend the initial DTD.
One way would be to add attributes or change default attribute values.
This seems easy to accomplish because XML allows one element to have
multiple attribute declarations, where attribute declarations are merged.
However, it is not clear to me how to best accomodate new element types
that might be added.

Here are the approaches that I have so far envisioned:

(1) Place into the initial DTD an element called EXTENSIONS and give it a
contentspec of ANY (is "contentspec" the right term?).  Subsequent DTDs
would redefine EXTENSIONS to contain their own extensions, but each of
these DTDs would define still another EXTENSIONS element within the
overridden EXTENSIONS element.  For some reason this approach doesn't sit
well with me.  It seems that I would need to put an EXTENSIONS element
inside *every* element of the initial DTD if I think I might ever have to
extend that element.  Ugly!!!!

(2) In the initial DTD, define an element to have a contentspec of ANY if I
think it might ever need to be extended.  Now the application that eats
documents of this DTD would have to be a bit smarter, because it would have
to know that it is valid to ignore elements that it does not recognize.  It
also moves a lot more of the document validation into the application's
lap, because we aren't taking advantage of a DTD's ability to constrain
document content.  Ugly, again!!!!

(3) Design the initial DTD to be exactly the way I want it, and design
subsequent DTDs to be exactly the way I want them, except that any document
conforming to the second DTD must have a subtree (in the element hierarchy)
that conforms to the first DTD.  The second DTD need not be an extension of
the first DTD in the SGML sense of the word "extension."  Instead, the
ability to handle extended documents is completely the responsibility of
the applications.  Applications must throw out subtrees that they do not
recognize.  But then I have no way to leverage my initial DTD in the design
of my subsequent DTD, except to copy the initial DTD and to tweak the copy.
 When should I be using DTD inheritance?  Is it unreasonable to impose this
kind of behavior on my applications?  Is this ugly too?

Well, those are the only options I've come up with so far for allowing old
DTDs to be extended by adding new elements.  What are your opinions of
these approaches?  What options have I missed?  What other kinds of
extensions might I want to plan for, and what is the best way to plan for
them?  Anyone know where can I find a suitably knowledgable Buddha in the
high Himalayas?

Thanks el mucho for whatever help you can provide.

(BTW, I tried to find the relevant information by searching the xml-dev
archive, but I have trouble using simple search engines to find
information.  Normally I use AltaVista's advanced search form, but
AltaVista has not walked xml-dev for eons.  Is there any way to invite
AltaVista for a walk accross our grounds?)
--
Joe Lapp, Technology Analyst | jlapp at webmethods.com
webMethods, Inc.             | Voice: 703-267-1726
http://www.webmethods.com    |   Fax: 703-352-0370

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)