Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Note that this external parameter entity declaration and the reference to it are located in the internal DTD subset. Note, too, that I have explicitly stated that the XML document is not a standalone document.

If you are not going to validate an XML document, you must always be wary of what can go wrong with external parameter entities that contain markup declarations. The following shows an external parameter entity being used in an internal DTD subset to include some declarations from an external file:

<?xml version=”1.0" standalone=”yes”?>
<!DOCTYPE menu [
   <!ELEMENT menu (#PCDATA, front, meals+, back)*>
   <!ATTLIST menu title CDATA “Carte Blanche”>
   <!ENTITY % entrees SYSTEM “entrees.xml”>
   %entrees;
   <!ATTLIST menu desserts CDATA “Sweet Temptations”>
]>
<menu>
   <front>Sunday, July 11, 1998</front>
   …
</menu>

When this XML document is parsed but not validated, the value of the menu element’s title attribute will be “Carte Blanche”. The XML processor sees the declaration of the title attribute, even though it is inside the internal DTD subset. Because it isn’t validating (the document claims that it is a standalone document), the XML processor is not allowed to process any external entity references. The value of the desserts attribute has to remain unknown.

The default value (“Sweet Temptations”) has been declared, but the XML processor isn’t allowed to use it. Maybe it does seem odd, but what is contained in the entrees.xml file that is referenced by the entrees external parameter entity? It doesn’t really matter because the XML processor is not allowed to know, either. Suppose, though, that the entrees.xml file contained element declarations; the entity reference is inside the internal DTD subset, so it would be quite legal to do so. Suppose, too, that the file contained the following attribute declaration:

<!ATTLIST menu desserts CDATA “Bitter Experiences”>.

This would mean that the desserts attribute could not have the value “Sweet Temptations”. So, be careful with external parameter entities in the internal DTD subset, and consider the possible confusion they could cause when the recipient is not validating (something you have little or no control over). The only way you can protect yourself from this is to always use a standalone document declaration.

The purpose of this declaration is really to indicate to the recipient that the DTD could change the document and that the DTD should be retrieved if the recipient wants to be certain that what it sees is the same as what the application that created the document sees. Parsing the DTD would mean that external entity references would be dereferenced, and so the external declaration would then be found. Although the declaration has no effect on the XML processor, by changing the value of the standalone document declaration to “no,” you can simply inform the recipient that validation is needed if the document is to be seen as intended.

Conditional Markup

When you learned about the DTD design step of constraining the model, one recommendation was that you could consider making two versions of the same DTD. You could use a loose DTD during authoring when, for example, not all the content may have been filled in, but you still want to validate the document, and you could use another, tighter DTD for the finished XML document. A way to do this uses conditional sections of the DTD and parameter entities.

This involves blocking the two variant declarations of the DTD inside blocks and starting the block with a reference to a parameter entity:

<![%AuthoringSwitch;[
   <!ENTITY % body “chapter, intro?, section*”>
]]>
<![%FinalSwitch;[
   <!ENTITY % body “chapter, intro, section+”>
]]>