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

Tokenized Types Tokenized attributes are classified according to what their value or values can be:

•  ID—This type of attribute serves as an identifier for the element. No two elements can have the same ID value in the same document. An ID value must comply with the standard XML naming rules. An ID attribute type can be applied to any attribute, but it is standard practice to restrict its use to an attribute that is also called ID because this makes it easier to find.
An example of an ID type declaration is

<!ATTLIST book
   id ID>

and you would then use it like this:

<book id=”A51">

•  IDREF—This type of attribute is a pointer to an ID (an ID reference). The value must match the value of an ID type attribute that is declared somewhere in the same document.

•  IDREFS—The value of this type of attribute consists of one or more IDREF type values, separated by spaces.
An example of an IDREFS type declaration is

<!ATTLIST book
          authors IDREFS>

and you would then use it like this:

<book authors=”A51 A62 B87">

•  ENTITY—This type of attribute is a pointer to an external entity that has been declared (in the DTD, in either the external or internal DTD subset). The value of the attribute is the name of the entity, which can consist of name characters only. The XML document can no longer be a standalone document if you use external entities. It is a little early to learn about external entities, but we will return to them in Chapter 15, “XML Characters, Notations, and Entities.”

•  See “Entities,” p. 391.

•  ENTITIES—The value of this type of attribute consists of one or more ENTITY type values, separated by spaces.
ENTITY and ENTITIES type attributes are normally used to refer to things such as graphics files and other unparsed data:

<!ELEMENT graphic EMPTY>
<!ATTLIST graphic boardno ENTITY>

•  NMTOKEN—The value of this type of attribute is a “name token” string consisting of any mixture of name characters.

•  NMTOKENS—The value of this type of attribute consists of one or more NMTOKEN type values, separated by spaces.

Enumerated Types Enumerated attributes have values that are simply a list of possible values. Each value has to be a valid name token (NMTOKEN). The following is an example:

<!ATTLIST paint
          COLOR (RED | YELLOW | GREEN) “RED”>

When the list of possible values is prefixed by the keyword NOTATION, the notations listed as possible values must have been declared already:

<!ATTLIST image
          type NOTATION (GIF | JPEG | PNG) “GIF”>

• See “Notations,” p. 389.

When matching an attribute value against the allowed values specified in the attribute definition, the XML processor carries out a match (not case sensitive) for all attributes except those that are of the CDATA, IDREF, or IDREFS type.

Attribute Defaults You can add a keyword to the end of an attribute specification to specify what action the XML processor should take when you leave out (or forget) the attribute in a particular start tag.

Three keywords are possible:

•  #REQUIRED means that the attribute is required and should have been there. If it’s missing, it makes the document invalid. An example of a required declaration is

<!ATTLIST book
         author ID #REQUIRED>

Normally, ID type attribute values are specified as being required (and you will learn later that they must be specified as required if the document is to be validated).

•  #IMPLIED means that the XML processor must tell the application that no value was specified (it is then up to the application to decide what it is going to do). An example of an implied declaration is

<!ATTLIST section
          number #IMPLIED>

Implied attribute values are often used for things such as section and list item numbering, where the application can calculate the value itself simply by counting.

•  If the default value is preceded by the keyword #FIXED, any value that is specified must match the default value, or the document will be invalid.
The following are examples of attribute declarations with default values:

<!ATTLIST termdef
          id ID #REQUIRED
          name CDATA #IMPLIED>
<!ATTLIST list
          type (roman | arabic | Roman | Arabic) “roman”>
<!ATTLIST form
          method CDATA #FIXED “POST”>

Well-Formed XML Documents

Elements, attributes, and entities are the three primary building blocks for XML documents. Using only elements, you can create true XML documents. Using all three objects, you can create quite complex XML documents; you could fulfill the needs of about 90% of the applications for which you would want to use XML.

For such documents to be properly usable—for an XML processor to parse these documents successfully—they must be well formed. According to the XML standard, a data object is not officially an XML document until it is well formed. You have already encountered most of the rules that an XML document must obey in order to be well formed, but to round out this discussion of XML documents, we’ll review them all:

A document that you are able to create now using only elements, attributes, and entities is well formed if

•  It contains one or more elements.

•  It has only one element (the document, or root element) that contains all the other elements.

•  Its elements (if it contains more than one element) are properly nested inside each other (no element starts in one element and ends in another).

•  The names used in its element start tags and end tags match exactly.

•  The names of attributes do not appear more than once in the same element start tag.

•  The values of its attributes are enclosed in either single or double quotes.

•  The values of its attributes do not reference external entities, either directly or indirectly.

•  The replacement text for any entity referenced in an attribute value does not contain a < character (it can contain the string &lt;).

•  Its entities are declared before they are used.

•  None of its entity references contains the name of an unparsed entity.

•  Its logical and physical structures are properly nested.

Sample XML Applications

To get a better idea of what kinds of real-world applications can be created using XML, you can check out the following:

•  Synchronized Multimedia Integration Language (SMIL)—Enables integrating a set of independent multimedia objects into a synchronized multimedia presentation (http://www.w3.org/TR/REC-smil/).

•  Mathematical Markup Language (MathML)—Can be used to allow the description of mathematical notation, capturing both its structure and content (http://www.w3.org/TR/REC-MathML/).

•  Chemical Markup Language (CML)—Enables the markup of information from the fields of molecular and biological chemistry (http://www.venus.co.uk/omf/).