[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Compound Documents - necessary for success?

  • From: Chris von See <cvonsee@o...>
  • To: xml-dev@i...
  • Date: Tue, 02 Feb 1999 13:04:29 -0600

RE: Compound Documents - necessary for success?
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.



"Beware of all enterprises that require new clothes."

-- Thoreau

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.