Should I use defaults in my DTD?

Joshua E. Smith jesmith at
Wed May 5 03:59:02 BST 1999

Two more questions were raised as I memorized the XML spec (heh, heh).

1) Should I specify defaults in my DTD?

My application knows what all the default values should be, so,
technically, all the attributes on my elements could be #IMPLIED.  However,
it would seem likely to me that a good editor might tell the user what
attributes exist for a given element they've inserted, and show them the
default values from the DTD.  The user could then easily decide what
attributes need non-default values without looking in the object model

However, I'm a little paranoid that some not-so-smart editors might read
the DTD, get all the defaults, treat them as though they were specified by
the user, and dump tons of default attributes into the saved file causing
massive bloat.  Would an editor really do that?  (In their book, Ian & Liam
seemed to imply that they thought one might.)

2) Should I use entities for URL attributes?

Since the XML spec has gone to all that trouble to support external
unparsed entities, it seems a little callous for me to call my attributes
which are URLs ordinary CDATA.  However, I have a really hard time seeing
any value in making the user of my DTD go to the trouble of declaring the
various JPGs and such as entities, when I know I'm just going to use the
URL string anyway.

Am I missing something?  Is there a reason why:

[Up in the DTD...]
<!ENTITY TheImage SYSTEM "TheImage.jpg" NDATA JPG>

[Down in the document...]
<texture image="TheImage" />

is preferable to:

[Alone in the document...]
<texture image="TheImage.jpg" />

The latter is so much simpler...

-Joshua Smith

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list