The IDREF allows us to create links and cross references within the document. The values of IDREF must meet the same conditions as ID. They must also be the same as the value of some ID attribute value within the document.

We cannot use an IDREF to point to a document that is not within the document. In such a case, we can use ID and IDREF to cross reference information instead of repeating it.

If a document contained the declaration as the Person element, we can have the declarations as shown, elsewhere in the DTD.

<!ELEMENT AccountHolder EMPTY>
<!ATTLIST AccountHolder
id IDREF #REQUIRED>

In such cases, we have to know implicitly that the attribute id refers to the PIN attribute in Person. Instead of duplicating the entire Person element within the AccountHolder, we can have an empty element with an IDREF. Whenever we need the Person information, the application can search for a Person element with the PIN attribute whose value that matches the id attribute in a specified AccountHolder.

<Person PIN= "405060">
<Name>…</Name>
…
</Person>
…
<AccountHolder>

The IDREFS type comes into purpose when we want to link to many other elements.

It allows us to model one-to-many relationships. The value of this attribute is a series of ID values separated by whitespace. The individual Ids must meet the ID type constraints and must match up with ID attribute values elsewhere in the document.

Entities are used within the declarations of the attributes for efficiency and reuse. If there is a construction that appears many times, we can declare an entity representing the construction and then refer to it, whenever the construction is needed. ENTITY is therefore called as Replaceable Content.

Entities may also be used to include unparsed entities as valid attribute values. This is exactly the mechanism by which a document author can point to data other than XML markup.

For example, if we want to include some XML data, we can do this with an entity is as shown. We start by declaring the attribute to be of type ENTITY.

<!ENTITY Turnover_chart SYSTEM "Turnover_chart.gif" NDATA gif>

Elsewhere in the DTD we declare the entity.

We can thus in the XML refer the image through the attribute.

<ATTLIST MonthlyTurnover
Month_graph ENTITY #IMPLIED>

To use an ENTITY as an attribute type, four things need to be done. Of these four three are declarations in the DTD. The fourth involves a specific document instance. They are declare a notation, declare one or more entities for use with the attribute, declare an attribute of type ENTITY for some element and create an instance of the element type in a document, providing the attribute and an entity name as the value.

Just as we were able to use multiple IDREF values as a single attribute value, we can also do the same with entities. This type is called as ENTITIES. This works similar to IDREFS.

Each name in the attribute value must conform to the rules of the ENTITY type, and individual entity names are separated by whitespace.

Sometimes we might want to treat the value of an attribute as a distinct token rather than text and want to leave the list of values imprecise. In such a case, we can use name token, which is abbreviated as NMTOKEN and NMTOKENS.

Similar to IDREFS and ENTITIES, attributes of type NMTOKENS can be declared, that have values comprised of multiple name tokens. Each name must be a valid name token and items separated by whitespace.

Although, they must conform to the rules for names that were discussed under elements, they are free of one restriction. They are to be comprised of letters, digits and punctuation marks like colon, underscore, period and hyphen, unlike element and attribute names, any of these can be used as the first character of an NMTOKEN. The figure shows an example of an NMTOKEN attribute.

<!ATTLIST Employee
security_level NMTOKEN #REQUIRED>

<employee security_level="trusted">…

The example says that an Employee element may have an attribute named security level whose level conforms to the rules for XML name tokens. We could use this to control access to confidential information. By choosing NMTOKEN, document authors will be able to accommodate new security level designations as they are created without editing the DTD every time. Any value that conforms to the rules for comprising NMTOKEN values will be accepted as the value for this attribute.

An XML parser is not set to deal with binary data formats. To overcome this problem, notations are used which identify the format of external data items that we would want to link to XML documents.

We need the notation declaration to declare a name for the notation and associate the name with an external handler. The parser refers the foreign data to the handler for processing.

The handler declaration works in same manner as DTD locates files in DOCTYPE declaration. It can be PUBLIC or STATIC and also it must include the name of the external handler. The figure shows an example of NOTATION declaration.

With notations, XML documents can be used as the unifying document of a collection of dissimilar datatypes. This is useful for legal reports, medical reports and multimedia presentations. XML, however, only gives the minimal set of tools. Considerable effort is needed to build the proper presentation semantics into an application.

<!ATTLIST Imager type NOTATION (gif | jpg) "gif">
<Image type="jpg">…

An attribute can be typed as a notation name using the keyword NOTATION as shown. The above declaration says that an Image that is a notation. The acceptable values of the attribute are gif and jpg. On leaving the attribute without an instance, the parser would assume that the attribute appeared with the default value, gif. In the instance shown, however the value jpg overrides the default.

Name tokens are open ended. The format of values of NMTOKEN and NMTOKENS are restricted by name rules, otherwise the set of permissible values are open. In many cases, we have a small set of character string values that we want to be permitted such as YES or NO. These are the useful enumerations for decision-making.

The enumeration attribute is declared by placing a group of values where the type keyword appears. The group consists of parentheses enclosing the permitted values separated by the pipe symbol (|). The values are not enclosed by quotation marks but like names as in XML, are case sensitive.

The instance of an attribute in the document must include only one of the permitted values as it appears in the attribute declaration. Like any other attribute value, the enumerated value should be enclosed by quotation marks.

<!ATTLIST Employee
manager (yes | no) #REQUIRED>

<!ATTLIST ClassifiedDoc
security_level (unclassified | secret | Top_secret) #REQUIRED>

In the first case only the values YES and NO are allowed. YES, NO and MAYBE will all be rejected as invalid. It is important to respect case sensitivity, as it is to emphasize the values provided in the enumeration declaration. When composing an enumeration for values that may be manually entered by a user, all the variations produced by modifying the case of the values must be considered.

Conditional Sections are those statements that are parsed by the compiler, only if certain conditions are met. But in DTDs this feature is restricted, there is no conditional expression to be evaluated at run time. DTDs include conditional sections that instruct parser to include or ignore a section of declarations. These are useful for controlling blocks of declarations in a DTD. The conditional sections are, however, not allowed in the internal subset of the DTD.

The declaration of conditional sections consists of exclamation mark, square left bracket and a keyword followed by a block of declarations delimited by square brackets. If the keyword is INCLUDE, the declarations in the block are considered being a part of the DTD for validation. On the other hand, the DTD declarations in the block are read but passed by the parser if the keyword is IGNORE.

DTDs have propelled XML through its early adoption phase. However, they suffer from few limitations. They use the syntax all of their own, distinct from that of document instances. Importantly, it would be beneficial if XML parsers could give an application easy access to the declarations in DTDs they process. We cannot use parsers to build dynamic DTDs.

DTDs are close constructs. The rules of an XML are wholly contained in the DTD. The DTD contains only the vocabulary and nothing else. There is no simple and clear way to promote extensibility in DTDs.

DTDs also lack datatype information. The only tool that is provided is the notation. This does little to allow us define our own types based on existing types.