Compound Documents - necessary for success?

[Chris von See]

At 05:52 PM 2/2/99 +0000, Mark Birbeck wrote:
>
>Well, sort of. But note that you can use namespaces even without using a
>DTD. A standalone document that is well-formed might still want to have
>the following, in order to provide clues to any application that is
>processing it:
>
>    <xml xmlns="uri:mybits" xmlns:dt="uri:datatypes">
>        <person>
>            <name dt:type="string">Fred</name>
>            <contract type="short-term" />
>            <hair type="greasy" dt:type="string">blonde</hair>
>        </person>
>    </xml>
>
>In this example, if the application was going to process 'type' in a
>certain way (say an XSL processor), then it needs the namespaces to help
>it work out which 'type' is which. Also, if the namespace wasn't there,
>then you wouldn't be able to use both 'type' attributes in the same
>element. But note that no schemas need be involved.

Without a DTD or schema on which to "hang your hat", so to speak, you're
vesting the application with the knowledge of what the various
namespace-qualified constructs mean.  This strikes me as a Very Bad Thing,
because it leaves individual applications to interpret (potentially,
interpret very differently) what a particular attribute or element means.
Generating a specific meaning and rules for usage for a particular DTD or
schema isn't "automagic", but at least it forces people to think about what
they're doing and lends some semblance of order.   For small applications
you can get away with not having such an anchor point, but for anything
larger than a few documents you're asking for trouble.

>
>Conversely, if you devise a DTD that uses another DTD, you don't
>necessarily need to use namespaces. In the height/player example given
>before there is no ambiguity, so why would you introduce a namespace?

Granted, as long as there are no conflicts in naming between the DTDs.
However, as soon as you change a DTD you get into problems with DTD
versioning, and as soon as you clone it to add the new DTD reference the
proliferation of DTDs introduces a potential management problem.  Yuk.
 
>
>So, back to compound documents. I think as a stop-gap you need dynamic
>DTDs. Just as many features of XML are best implemented using dynamic
>documents generated from databases, why not generate a top-level DTD
>that contains whatever lower level DTDs it needs to define the relevant
>compound XML document? The top DTD would include some basic stuff for
>containing a list of documents, and then include whatever other DTDs it
>needs for each document in turn.

In order to do what you're proposing, you have to have knowledge
*somewhere* of what is and is not acceptable... just as RDBMS catalogs
govern the creation of dynamic DTDs for database data, so you would have to
provide some sort of intelligence in your DTD generation mechanism to
prevent unwanted, ambiguous usage.



Chris

------------------------------------

"Beware of all enterprises that require new clothes."

-- Thoreau

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)