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

The following list describes the different places in which an entity reference can occur and how it is treated there.

•  Inside an element—The reference appears anywhere after the start tag and before the end tag of an element.

•  In an attribute value—The entity reference occurs within either the value of an attribute in a start tag, or a default value in an attribute declaration.

•  Name in attribute value—The entity reference appears as a name, not as an entity reference, but as the value of an attribute that has been declared as type ENTITY or ENTITIES:

           <?xml version=“1.0” standalone=“yes”?>
           <!DOCTYPE graphic SYSTEM “graphic.dtd” [
             <!ELEMENT graphic (icon)+>
             <!ELEMENT icon EMPTY>
             <!ATTLIST icon
                       height   NMTOKEN #IMPLIED
                       nsoffset NMTOKEN #REQUIRED
                       width    NMTOKEN #IMPLIED >
             <!ENTITY icon8 SYSTEM “icon813.gif” NDATA gif>
           ]>
           <graphic>
             <icon source=“icon8”
                   height=“0.391in” nsoffset=“0.000in”
                   width=“0.429in”/>
           </graphic>

•  In an entity value—The reference appears in a parameter or entity’s value in the entity’s declaration.

•  In the DTD—The reference appears within either the internal or external subset of the DTD, but outside of an entity or attribute value.

An entity’s replacement text may contain character entity, parameter entity, and general entity references. Character references and parameter entity references in the value of an entity are resolved when the entity is resolved. General entity references are ignored.

When an entity reference is replaced, the entity’s replacement text is retrieved and processed in place of the reference itself, as though it were part of the document at the location the reference was recognized. The replacement text may contain both character data and (except for parameter entities) markup, which is recognized in the usual way, except that the replacement text of the entities amp, lt, gt, apos, and quot is always treated as data.

To validate a document, the replacement text for parsed entities also has to be parsed. If the entity is external and the document is not being validated, the replacement text doesn’t have to be parsed. If the replacement text isn’t parsed, the application is told of this, and it is up to the application to handle it.

When the name of an unparsed entity appears, as in the value of an attribute whose declared type is ENTITY or ENTITIES, the system and public (if any) identifiers for both the entity and its associated notation are simply passed to the application. The application is then responsible for any further processing (such as displaying the graphic file in a window).

Getting the Most Out of Entities

As you may remember, a fixed order exists in which the external and internal DTD subsets are read and interpreted. First the internal DTD subset is read and then the external DTD subset. If something is declared in the internal DTD subset, its declaration cannot be changed in the external DTD subset, although some things (such as additional attributes) can be added to declarations.

Used with a little careful planning, this hierarchical arrangement can enable you to construct your information collection (such as a Web site) to make the maximum use of shared data (see Figure 15.2):

•  Global declarations can be placed in a central DTD that governs all the documents. As far as each document is concerned, this central DTD is the (common) external DTD subset.
The central DTD references entities that contain common graphics (company logo graphics and letterhead material, special characters, and so on).

•  Local declarations can be placed in the internal DTD subset of each document. This enables each document to override the global declarations and tailor them for its own purposes.
The internal DTD subset in each document references any graphics and text that the particular document needs.

FIGURE 15.2  Using local and global entities.

Breaking the documents into modules and exploiting the order in which the internal and external DTD subsets occur allow you to modularize a lot of documents, but you can go even further than this when you need to. You can even modularize the DTD itself and collect the parts you need for a particular document type (although in this context you could almost call it a subtype).

Many (large) industrial implementations of SGML use this scheme. Some people call this a “pizza model” because you build your DTD out of a base (core) of essential elements and then add the toppings that you need for the particular document. Examples of major DTDs that use this are the Text Encoding Initiative DTD and the American Department of Defense DTDs used for Interactive Electronic Technical Manuals (IETM).

This same approach could just as easily be used in XML. In fact, it could probably be used more easily because XML’s capability to include Internet URLs as the locators for fragments makes it far easier to physically distribute data while still being able to bring it all together as a coherent set of information.

Although you have to use external entities to include binaries, such as graphics files, in your formatted XML output, entities can be a wonderful tool for breaking up the task of managing a complex collection of many documents into manageable chunks. By the considered use of internal and external text entities combined with the hierarchical ordering applied to interpreting the two DTD subsets, you can implement a staged hierarchy of template content. At the global level, you can safely set up default settings and then let individual XML documents implement local overriding changes as you need them.