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

Elements or Attributes?

The idea of separating elements and attributes in an XML database description is one of the many ways that a distinction can be made between the use of elements and attributes. This question surfaces regularly in SGML circles, and even now it has never really been answered with any degree of conviction. The database example shows one possible answer, but it is only one of many. The following are some things to keep in mind:

•  Elements can be remapped using architectural forms, and attributes can be remapped using XLink; this is, therefore, not a decisive reason for selecting either an element or an attribute.

•  Historically, attributes have been reserved for intangible, abstract properties, such as color and size, and elements are reserved for physical components. To deviate from this usage, especially in an SGML context, may confuse people.

•  It may be easier to edit elements in XML editing tools than attributes, and attribute values may not be so readily displayed as element content. This would favor elements when dealing with human authors.

•  An XML processor is able to check the content of an attribute value more easily than it can check the content of an element. It can’t check an attribute value for much, but it can barely check the content of an element at all.

•  The attributes of elements from separate XML documents can be merged quite easily. It can be extremely hard to merge elements, and so, in a distributed environment, attributes may have the edge over elements.

•  In collaborative (multiple) author environments, it is reasonably easy to split XML documents into fragments based on the element structure rather than the attribute values.

•  Sensibly named elements can make (human) authoring easier and less confusing. When selecting an element to contain a list, for example, it’s pretty obvious to the human writer that she should choose a list element. However, the selection of the correct attribute (and you will quite often see such cryptic attribute values as ordered and unordered, which come from HTM) can be less than obvious and not very visible. The choice of container elements instead, such as list.numbered and list.bulleted, may make the author’s life much simpler.

From these concepts, you may notice a general trend. Generally speaking, when human beings are expected to create or work with the XML documents, it can be better to use elements rather than attributes.

Saving Yourself Typing with Parameter Entities

You will learn a lot more about entities in the next chapter. For the moment, we are concerned with one particular type of entity called the parameter entity, which can be extremely useful in XML DTDs. Parameter entities are basically like the character entities you learned about earlier. They, too, behave like macros and can be used as abbreviations for strings. However, where character entities serve as abbreviations for character strings, parameter entities serve as shortcuts for markup declarations and parts of declarations. Obviously, because they are concerned with markup declarations, they can be used only in DTDs. In fact, their use is a little more restrictive than this:

•  In the internal DTD subset, parameter entities can be used only between other markup declarations.

•  In the external DTD subset, parameter entities can be used both between and inside other markup declarations.

To make sure no confusion occurs between parameter entities and character entities, the syntax for declaring and referring to parameter entities is quite different from the syntax for a character entity; a parameter entity uses a percent sign, as in the following example:

<!ENTITY % heading “H1 | H2 | H3 | H4 | H5 | H6”>
<!ENTITY % body.content “(%heading | %text | %block | ADDRESS)*”>
<!ELEMENT BODY %body.content>

The heading parameter entity saves a lot of typing (note that you could use this particular trick only in the external DTD subset). Parameter entities can also be used to make DTD declarations a little more comprehensible, as in the following example:

<!ENTITY % color “CDATA”>
<!ENTITY % body-color-attrs “
        bgcolor %color #IMPLIED
        text    %color #IMPLIED
        link    %color #IMPLIED
        vlink   %color #IMPLIED
        alink   %color #IMPLIED
“>
<!ELEMENT BODY  %body.content>
<!ATTLIST BODY
          background %URL #IMPLIED
          %body-color-attrs;>

Both examples shown here use internal parameter entities; no external file is required for the XML processor to be able to determine the contents of the entities. It is also possible to have external parameters, as you will learn next, and these are used for quite different purposes.

Modular DTDs

Earlier, you learned that techniques can be used to split up particularly complex DTDs. This is another use for external parameter entities. For example, the following DTD fragment declares and then immediately references a set of character entity declarations contained in an external file (this is such a common use for parameter entities that an extensive set of public identifiers exists that covers most of the less commonly used characters):

<!ENTITY % ISOnum PUBLIC “ISO 8879:1986//ENTITIES Numeric and Special Graphic//
EN”>
%ISOnum;

External parameter entities really come in handy when you decide to reuse the results of work that you have invested in the development of other DTDs. Over the years, the declarations of the elements in a table, for example, have gradually become standardized around a model called the cals table model (named after the American Department of Defense Computer Assisted Logistic Support initiative, under which a lot of early SGML developments were funded). It is quite hard to improve on this model (tables are pretty standard), and so it is often provided as a common DTD fragment that all other DTDs can reference when they need it:

<?xml version=”1.0" standalone=”no”?>
<!DOCTYPE book SYSTEM “book.dtd” [
    <!ENTITY % calstable SYSTEM “cals.dtd”>
    %calstable;
]>