Document type definition

Associating DTDs with documents

• an optional external subset
• an optional internal subset.

Examples

Markup declarations

Element type declarations

• EMPTY for specifying that the defined element allows no content, i.e., it cannot have any children elements, not even text elements ;
• ANY for specifying that the defined element allows any content, without restriction, i.e., that it may have any number and type of children elements ;
• or an expression, specifying the only elements allowed as direct children in the content of the defined element; this content can be either:
• * a mixed content, which means that the content may include at least one text element and zero or more named elements, but their order and number of occurrences cannot be restricted; this can be:
• ** : historically meaning parsed character data, this means that only one text element is allowed in the content ;
• ** *: a limited choice of two or more child elements may be used in any order and number of occurrences in the content.
• * an element content, which means that there must be no text elements in the children elements of the content. Such element content is specified as content particle in a variant of Backus–Naur form without terminal symbols and element names as non-terminal symbols. Element content consists of:
• ** a content particle can be either the name of an element declared in the DTD, or a sequence list or choice list. It may be followed by an optional quantifier.
• *** a sequence list means an ordered list of one or more content particles: all the content particles must appear successively as direct children in the content of the defined element, at the specified position and relative order;
• *** a choice list means a mutually exclusive list of two or more content particles: only one of these content particles may appear in the content of the defined element at the same position.
• ** A quantifier is a single character that immediately follows the specified item it applies to, to restrict the number of successive occurrences of these items at the specified position in the content of the element; it may be either:
• *** + for specifying that there must be one or more occurrences of the item — the effective content of each occurrence may be different;
• *** * for specifying that any number of occurrences is allowed — the item is optional and the effective content of each occurrence may be different;
• *** ? for specifying that there must not be more than one occurrence — the item is optional;
• *** If there is no quantifier, the specified item must occur exactly one time at the specified position in the content of the element.

Attribute list declarations

• the declared name of the attribute,
• its data type,
• and its default value.

Entity declarations

• Internal entities are associating a name with any arbitrary textual content defined in their declaration. When a named entity reference is then encountered in the rest of the document, and if this entity name has effectively been defined as a parsed entity, the reference itself is replaced immediately by the textual content defined in the parsed entity, and the parsing continues within this replacement text.
• * Predefined named character entities are similar to internal entities: 5 of them however are treated specially in all SGML, HTML and XML parsers. These entities are a bit different from normal parsed entities, because when a named character entity reference is encountered in the document, the reference is also replaced immediately by the character content defined in the entity, but the parsing continues after the replacement text, which is immediately inserted literally in the currently parsed token. This allows some characters that are needed for the core syntax of HTML or XML themselves to be escaped from their special syntactic role. Predefined character entities also include numeric character references that are handled the same way and can also be used to escape the characters they represent, or to bypass limitations in the character repertoire supported by the document encoding.
• * In basic profiles for SGML or in HTML documents, the declaration of internal entities is not possible.
• * Instead, HTML standards predefine a large set of several hundred named character entities, which can still be handled as standard parsed entities defined in the DTD used by the parser.
• External entities refer to external storage objects. They are just declared by a unique name in the document, and defined with a public identifier and/or a system identifier specifying where the source of their content. They exist in fact in two variants:
• * parsed external entities that are not associated in their definition to a named annotation, in which case validating XML or SGML parsers retrieve their contents and parse them as if they were declared as internal entities ;
• * unparsed external entities that are defined and associated with an annotation name, in which case they are treated as opaque references and signaled as such to the application using the SGML or XML parser: their interpretation, retrieval and parsing is left to the application, according to the types of annotations it supports.
• * External entities are not supported in basic profiles for SGML or in HTML documents, but are valid in full implementations of SGML and in XML 1.0 or 1.1.

Notation declarations

&example1SVG;

• All external entities used by these standard document types are referenced by simple attributes, declared with the CDATA type in their standard DTD
• All external entities for additional meta-data are referenced by either:
• * Additional attributes
• * Additional elements within their own attributes
• * Standard pseudo-attributes in XML and XHTML.

• If the application can't use any notation, these notations may be either ignored silently by the application or the application could signal an error.
• Otherwise, the applications decide themselves how to interpret them, then if the external entities must be retrieved and then parsed separately.
• Applications may then signal an error, if such interpretation, retrieval or separate parsing fails.
• Unrecognized notations that may cause an application to signal an error should not block interpretation of the validated document using them.

  XML DTDs and schema validation

XML DTD schema example

1. people_list is a valid element name, and an instance of such an element contains any number of person elements. The * denotes there can be 0 or more person elements within the people_list element.
2. person is a valid element name, and an instance of such an element contains one element named name, followed by one named birthdate, then gender and socialsecuritynumber. The ? indicates that an element is optional. The reference to the name element name has no ?, so a person element must contain a name element.
3. name is a valid element name, and an instance of such an element contains "parsed character data".
4. birthdate is a valid element name, and an instance of such an element contains parsed character data.
5. gender is a valid element name, and an instance of such an element contains parsed character data.
6. socialsecuritynumber is a valid element name, and an instance of such an element contains parsed character data.

• XML Schema, also referred to as XML Schema Definition, has achieved Recommendation status within the W3C, and is popular for "data oriented" XML use because of its stronger typing and easier round-tripping to Java declarations. Most of the publishing world has found that the added complexity of XSD would not bring them any particular benefits, so DTDs are still far more popular there. An XML Schema Definition is itself an XML document while a DTD is not.
• RELAX NG, which is also a part of DSDL, is an ISO international standard. It is more expressive than XSD, while providing a simpler syntax, but commercial software support has been slow in coming.

  Security