Mark.Birbeck at iedigital.net
Wed Jun 16 14:29:39 BST 1999
Paul Prescod wrote:
> At the end of a day of training (brainwashing) my students
> usually say: "Why would I spend twenty lines of XML syntax
> saying what a DTD can say in one line?"
> I am genuinely interested in improving XML usability,
> however, so I would like to hear counter-arguments.
I think ultimately it is because it is XML. You now have a document that
can be parsed and processed with the same tools that you use for all
your other documents. This makes a number of things a lot easier. For
example, it is surely theoretically possible to create an XSLT document
from two schema, that converts a document of type A to one of type B.
This could be done with a series of XSLT files. Also, as other XML
techniques become standardised, XML-based schema automatically 'inherit'
them. For example, when we have got a working approach to transclusion
with XLinks, I could include your schema inside my schema. With XPointer
I might even just include a small part of your schema. Of course some of
these things could be carried out with DTDs - the transformation and
including other DTDs - but they are done with techniques that only exist
for DTDs, and no other realm of XML.
For me, though, the main problem with DTDs is not their syntax, but the
difficulty in validating a document that is based on two or more DTDs.
With the mechanism as it stands you need to create a third schema which
is the amalgam of both schemas, but this is impractical for most real
world uses. Imagine that I include a link in a document to my profile,
which is an XLink and is to be transcluded. This means that the parser
needs to know the type of my profile after including it, so that it can
validate it. But what if I change my profile from a boring load of text
to a video, but the XLink remains the same? The DTD containing the link
to the profile would need to have the video and text DTDs already there,
which is impractical if new schemas for profiles are continually added.
With the current XML-Data approach, I can define the schema to be used
on a per-node basis, so including a node also includes the information
needed to validate it.
Anyway, if I may give my humble pointer to the future, manual generation
of this stuff is not going to be around for long. As I have mentioned in
previous discussions, I have devised a simple system whereby a
hierarchical database functions as a massive XML document, and nodes and
their children can be extracted as needed. I'm sure many others have
done this, so this is not a great claim, however, this has now been
extended so that the schemas that define this document and all its
sub-documents can also be extracted at any level. This means that you
only actually extract the amount of schema you need for the document
being exported, and it makes schema very easy to maintain (you just have
to maintain the database). So, to illustrate the point, I have 'objects'
of type article which can contain objects of type paragraph. When I
export an article I place on the article node a pointer to the article
schema. All the latter does is pull out schema information for the
article and all its children. However, if asked to export just a
paragraph of text from an article, I attach to that node a pointer to
the paragraph schema. Why pass any more? The validater doesn't need it.
Mark.Birbeck at iedigital.net
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/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev