Adocument type definition (DTD) is a specification file that contains a set ofmarkup declarations that define adocument type for anSGML-familymarkup language (GML,SGML,XML,HTML). The DTD specification file can be used to validate documents.
A DTD defines the valid building blocks of an XML document. It defines the document structure with a list of validated elements and attributes. A DTD can be declared inline inside an XML document, or as an external reference.[1]
A namespace-aware version of DTDs is being developed as Part 9 of ISODSDL. DTDs persist in applications that need special publishing characters, such as theXML and HTML Character Entity References, which derive from larger sets defined as part of theISO SGML standard effort.XML uses a subset ofSGML DTD.
As of 2009[update], newerXML namespace-awareschema languages (such asW3C XML Schema andISO RELAX NG) have largely superseded DTDs as a better way to validate XML structure.
A DTD is associated with an XML or SGML document by means of adocument type declaration (DOCTYPE). The DOCTYPE appears in the syntactic fragmentdoctypedecl near the start of an XML document.[2] The declaration establishes that the document is an instance of the type defined by the referenced DTD.
DOCTYPEs make two sorts of declarations:
The declarations in the internal subset form part of the DOCTYPE in the document itself. The declarations in the external subset are located in a separatetext file. The external subset may be referenced via apublic identifier and/or asystem identifier. Programs for reading documents may not be required to read the external subset.
Any valid SGML or XML document that references anexternal subset in its DTD, or whose body contains references toparsed external entities declared in its DTD (including those declared within itsinternal subset), may only be partially parsed but cannot be fully validated byvalidating SGML or XML parsers in theirstandalone mode (this means that these validating parsers do not attempt to retrieve these external entities, and their replacement text is not accessible).
However, such documents are still fully parsable in thenon-standalone mode of validating parsers, which signals an error if it can not locate these external entities with their specifiedpublic identifier (FPI) orsystem identifier (a URI), or are inaccessible. (Notations declared in the DTD are also referencing external entities, but these unparsed entities are not needed for the validation of documents in thestandalone mode of these parsers: the validation of all external entities referenced by notations is left to the application using the SGML or XML parser). Non-validating parsersmay eventually attempt to locate these external entities in thenon-standalone mode (by partially interpreting the DTD only to resolve their declared parsable entities), but do not validate the content model of these documents.
The following example of a DOCTYPE contains both public and system identifiers:
<!DOCTYPEhtmlPUBLIC"-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
All HTML 4.01 documents conform to one of three SGML DTDs. The public identifiers of these DTDs are constant and are as follows:
The system identifiers of these DTDs, if present in the DOCTYPE, areURI references. A system identifier usually points to a specific set of declarations in a resolvable location. SGML allows mapping public identifiers to system identifiers incatalogs that are optionally available to the URI resolvers used by documentparsing software.
This DOCTYPE can only appearafter the optionalXML declaration, and before the document body, if the document syntax conforms to XML. This includesXHTML documents:
<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><!-- the XHTML document body starts here--><htmlxmlns="http://www.w3.org/1999/xhtml">...</html>
An additional internal subset can also be provided after the external subset:
<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!-- an internal subset can be embedded here -->]><!-- the XHTML document body starts here--><htmlxmlns="http://www.w3.org/1999/xhtml">...</html>
Alternatively, only the internal subset may be provided:
<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html [ <!-- an internal subset can be embedded here -->]><!-- the XHTML document body starts here--><htmlxmlns="http://www.w3.org/1999/xhtml">...</html>
Finally, the document type definition may include no subset at all; in that case, it just specifies that the document has a single top-level element (this is an implicit requirement for all valid XML and HTML documents, but not for document fragments or for all SGML documents, whose top-level elements may be different from the implied root element), and it indicates the type name of the root element:
<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html><!-- the XHTML document body starts here--><htmlxmlns="http://www.w3.org/1999/xhtml">...</html>
DTDs describe the structure of a class of documents via element and attribute-list declarations. Element declarations name the allowable set of elements within the document, and specify whether and how declared elements and runs of character data may be contained within each element. Attribute-list declarations name the allowable set of attributes for each declared element, including thetype of each attribute value, if not an explicit set of valid values.
DTD markup declarations declare whichelement types,attribute lists,entities, andnotations are allowed in the structure of the corresponding class of XML documents.[3]
An element type declaration defines an element and its possible content. A valid XML document contains only elements that are defined in the DTD.
Various keywords and characters specify an element's content:
EMPTY for specifying that the defined element allows no content, i.e., it cannot have any children elements, not even text elements (if there are whitespaces, they are ignored);ANY for specifying that the defined element allows any content, without restriction, i.e., that it may have any number (including none) and type of children elements (including text elements);(#PCDATA): historically meaningparsed character data, this means that only one text element is allowed in the content (no quantifier is allowed);(#PCDATA|''elementname''|...)*: a limited choice (in an exclusive list between parentheses and separated by "|" pipe characters and terminated by the required "*" quantifier) of two or more child elements (including only text elements or the specified named elements) may be used in any order and number of occurrences in the content.," comma character) of one or morecontent particles: all thecontent particles must appear successively as direct children in the content of the defined element, at the specified position and relative order;|" pipe character) of two or morecontent particles: only one of thesecontent particles may appear in the content of the defined element at the same position.+ 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 (zero or more) 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;For example:
<!ELEMENThtml(head,body)><!ELEMENTp(#PCDATA|p|ul|dl|table|h1|h2|h3)*>
Element type declarations are ignored bynon-validating SGML and XML parsers (in which cases, any elements are accepted in any order, and in any number of occurrences in the parsed document), but these declarations are still checked for form and validity.
An attribute list specifies for a given element type the list of all possible attribute associated with that type. For each possible attribute, it contains:
For example:
<!ATTLISTimgsrcCDATA#REQUIREDidID#IMPLIEDsortCDATA#FIXED"true"print(yes|no)"yes">
Here are some attribute types supported by both SGML and XML:
CDATAIDxml:id" with this type, without needing any declaration in the DTD, so the uniqueness constraint also applies to these defined identifiers when they are specified anywhere in a XML document.IDREF orIDREFSID in the DTD (or the unique element defined in an XML document with a pseudo-attribute "xml:id") and whose effective value is the same identifier;NMTOKEN orNMTOKENSENTITY orENTITIES(value1|...)|" pipe character) of textual values, where each value in the enumeration is possibly specified between'single' or"double" quotation marks if it's not a simple name token;NOTATION (notation1|...)|" pipe character) of notation names, where each notation name in the enumeration must also be declared in the document type declaration; this type is not supported in HTML parsers, but is valid in SGML and XML 1.0 or 1.1 (including XHTML and SVG).A default value can define whether an attribute must occur (#REQUIRED) or not (#IMPLIED), or whether it has a fixed value (#FIXED), or which value should be used as a default value ("…") in case the given attribute is left out in an XML tag.
Attribute list declarations are ignored bynon-validating SGML and XML parsers (in which cases any attribute is accepted within all elements of the parsed document), but these declarations are still checked for well-formedness and validity.
An entity is similar to amacro. The entity declaration assigns it a value that is retained throughout the document. A common use is to have a name more recognizable than anumeric character reference for an unfamiliar character.[5] Entities help to improve legibility of an XML text. In general, there are two types: internal and external.
An example of internal entity declarations (here in an internal DTD subset of an SGML document) is:
<!DOCTYPEsgml[<!ELEMENTsgmlANY><!ENTITY%std"standard SGML"><!ENTITY%signature" — &author;."><!ENTITY%question"Why couldn’t I publish my books directly in %std;?"><!ENTITY%author"William Shakespeare">]>
<sgml>&question;&signature;</sgml>
Internal entities may be defined in any order, as long as they are not referenced and parsed in the DTD or in the body of the document, in their order of parsing: it is valid to include a reference to a still undefined entity within the content of a parsed entity, but it is invalid to include anywhere else any named entity reference before this entity has been fully defined, including all other internal entities referenced in its defined content (this also prevents circular or recursive definitions of internal entities). This document is parsed as if it was:
<!DOCTYPEsgml[<!ELEMENTsgmlANY><!ENTITY%std"standard SGML"><!ENTITY%signature" — &author;."><!ENTITY%question"Why couldn’t I publish my books directly in standard SGML?"><!ENTITY%author"William Shakespeare">]>
<sgml>Whycouldn’tIpublishmybooksdirectlyinstandardSGML?—WilliamShakespeare.</sgml>
Reference to the "author" internal entity is not substituted in the replacement text of the "signature" internal entity. Instead, it is replaced only when the "signature" entity reference is parsed within the content of the "sgml" element, but only by validating parsers (non-validating parsers do not substitute entity references occurring within contents of element or within attribute values, in the body of the document.
This is possible because the replacement text specified in the internal entity definitions permits a distinction betweenparameter entity references (that are introduced by the "%" character and whose replacement applies to the parsed DTD contents) andgeneral entity references (that are introduced by the "&" character and whose replacement is delayed until they are effectively parsed and validated). The "%" character for introducing parameter entity references in the DTD loses its special role outside the DTD and it becomes a literal character.
However, the references to predefined character entities are substituted wherever they occur, without needing a validating parser (they are only introduced by the "&" character).
Notations are used in SGML or XML. They provide a complete reference to unparsed external entities whose interpretation is left to the application (which interprets them directly or retrieves the external entity themselves), by assigning them a simple name, which is usable in the body of the document. For example, notations may be used to reference non-XML data in an XML 1.1 document. For example, to annotate SVG images to associate them with a specific renderer:
<!NOTATIONtype-image-svgSYSTEM"image/svg">
This declares theMedia Type of external images with this type, and associates it with a notation name "type-image-svg". However, notation names usually follow a naming convention that is specific to the application generating or using the notation: notations are interpreted as additional meta-data whose effective content is an external entity and either a PUBLIC FPI, registered in the catalogs used by XML or SGML parsers, or a SYSTEM URI, whose interpretation is application dependent (here a MIME type, interpreted as a relative URI, but it could be an absolute URI to a specific renderer, or a URN indicating an OS-specificobject identifier such as a UUID).
The declared notation name must be unique within all the document type declaration, i.e. in the external subset as well as the internal subset, at least for conformance with XML.[6][7]
Notations can be associated to unparsed external entities included in the body of the SGML or XML document. ThePUBLIC orSYSTEM parameter of these external entities specifies the FPI and/or the URI where the unparsed data of the external entity is located, and the additionalNDATA parameter of these defined entities specifies the additional notation (i.e., effectively the MIME type here). For example:
<!DOCTYPEsgml[<!ELEMENTsgml(img)*><!ELEMENTimgEMPTY><!ATTLISTimgdataENTITY#IMPLIED><!ENTITYexample1SVGSYSTEM"example1.svg"NDATAexample1SVG-rdf><!NOTATIONexample1SVG-rdfSYSTEM"example1.svg.rdf">]>
<sgml><imgdata="example1SVG"/></sgml>
Within the body of the SGML document, these referenced external entities (whose name is specified between "&" and ";") arenot replaced like usual named entities (defined with a CDATA value), but are left as distinct unparsed tokens that may be used either as the value of an element attribute (like above) or within the element contents, provided that either the DTD allows such external entities in the declared content type of elements or in the declared type of attributes (here theENTITY type for thedata attribute), or the SGML parser is not validating the content.
Notations may also be associated directly to elements as additional meta-data, without associating them to another external entity, by giving their names as possible values of some additional attributes (also declared in the DTD within the<!ATTLIST...> declaration of the element). For example:
<!DOCTYPEsgml[<!ELEMENTsgml(img)*><!-- the optional "type" attribute value can only be set to this notation. --><!ATTLISTsgmltypeNOTATION(type-vendor-specific)#IMPLIED><!ELEMENTimgANY><!-- optional content can be only parsable SGML or XML data --><!-- The optional "title" attribute value must be parsable as text. The optional "data" attribute value is set to an unparsed external entity. The optional "type" attribute value can only be one of the two notations. --><!ATTLISTimgtitleCDATA#IMPLIEDdataENTITY#IMPLIEDtypeNOTATION(type-image-svg|type-image-gif)#IMPLIED><!-- Notations are referencing external entities and may be set in the "type" attributes above, or must be referenced by any defined external entities that cannot be parsed. --><!NOTATIONtype-image-svgPUBLIC"-//W3C//DTD SVG 1.1//EN""http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><!NOTATIONtype-image-gifPUBLIC"image/gif"><!NOTATIONtype-vendor-specificPUBLIC"application/VND.specific+sgml"><!ENTITYexample1SVGTitle"Title of example1.svg"><!-- parsed internal entity --><!ENTITYexample1SVGSYSTEM"example1.svg"><!-- parsed external entity --><!ENTITYexample1GIFTitle"Title of example1.gif"><!-- parsed internal entity --><!ENTITYexample1GIFSYSTEM"example1.gif"NDATAtype-image-gif><!-- unparsed external entity -->]>
<sgmltype="type-vendor-specific"><!-- an SVG image is parsable as valid SGML or XML text --><imgtitle="&example1SVGTitle;"type="type-image-svg">&example1SVG;</img><!-- it can also be referenced as an unparsed external entity --><imgtitle="&example1SVGTitle;"data="example1SVG"/><!-- a GIF image is not parsable and can only be referenced as an external entity --><imgtitle="&example1GIFTitle;"data="example1GIF"/></sgml>
The example above shows a notation named "type-image-svg" that references the standard public FPI and the system identifier (the standard URI) of an SVG 1.1 document, instead of specifying just a system identifier as in the first example (which was a relative URI interpreted locally as a MIME type). This annotation is referenced directly within the unparsed "type" attribute of the "img" element, but its content is not retrieved. It also declares another notation for a vendor-specific application, to annotate the "sgml" root element in the document. In both cases, the declared notation named is used directly in a declared "type" attribute, whose content is specified in the DTD with the "NOTATION" attribute type (this "type" attribute is declared for the "sgml" element, as well as for the "img" element).
However, the "title" attribute of the "img" element specifies the internal entity "example1SVGTitle" whose declaration that does not define an annotation, so it is parsed by validating parsers and the entity replacement text is "Title of example1.svg".
The content of the "img" element references another external entity "example1SVG" whose declaration also does not define a notation, so it is also parsed by validating parsers and the entity replacement text is located by its defined SYSTEM identifier "example1.svg" (also interpreted as a relative URI). The effective content for the "img" element be the content of this second external resource. The difference with theGIF image, is that the SVG image is parsed within the SGML document, according to the declarations in the DTD, where the GIF image is just referenced as an opaque external object (which is not parsable with SGML) via its "data" attribute (whose value type is an opaque ENTITY).
Only one notation name may be specified in the value of ENTITY attributes (there is no support in SGML, XML 1.0 or XML 1.1 for multiple notation names in the same declared external ENTITY, so separate attributes are needed). However multiple external entities may be referenced (in a space-separated list of names) in attributes declared with type ENTITIES, and where each named external entity is also declared with its own notation).
Notations are also completely opaque for XML and SGML parsers, so they are not differentiated by the type of the external entity that they may reference (for these parsers they just have a unique name associated to a public identifier (an FPI) and/or a system identifier (a URI)).
Some applications (but not XML or SGML parsers themselves) also allow referencing notations indirectly by naming them in the"URN:''name''" value of a standard CDATA attribute, everywhere a URI can be specified. However this behaviour is application-specific, and requires that the application maintains a catalog of known URNs to resolve them into the notations that have been parsed in a standard SGML or XML parser. This use allows notations to be defined only in a DTD stored as an external entity and referenced only as the external subset of documents, and allows these documents to remain compatible with validating XML or SGML parsers that have no direct support for notations.
Notations are not used in HTML, or in basic profiles for XHTML and SVG, because:
Even in validating SGML or XML 1.0 or XML 1.1 parsers, the external entities referenced by an FPI and/or URI in declared notations are not retrieved automatically by the parsers themselves. Instead, these parsers just provide to the application the parsed FPI and/or URI associated to the notations found in the parsed SGML or XML document, and with a facility for a dictionary containing all notation names declared in the DTD; these validating parsers also check the uniqueness of notation name declarations, and report a validation error if some notation names are used anywhere in the DTD or in the document body but not declared:
The XML DTD syntax is one of severalXML schema languages. However, many of the schema languages do not fully replace the XML DTD. Notably, the XML DTD allows defining entities and notations that have no direct equivalents in DTD-less XML (because internal entities and parsable external entities are not part of XML schema languages, and because other unparsed external entities and notations have no simple equivalent mappings in most XML schema languages).
Most XML schema languages are only replacements for element declarations and attribute list declarations, in such a way that it becomes possible to parse XML documents withnon-validating XML parsers (if the only purpose of the external DTD subset was to define the schema). In addition, documents for these XML schema languages must be parsed separately, so validating the schema of XML documents in pure standalone mode is not really possible with these languages: the document type declaration remains necessary for at least identifying (with aXML Catalog) the schema used in the parsed XML document and that is validated in another language.
A common misconception holds that anon-validating XML parser does not have to read document type declarations, when in fact, the document type declarations must still be scanned for correct syntax as well as validity of declarations, and the parser must still parse all entity declarations in theinternal subset, and substitute the replacement texts of internal entities occurring anywhere in the document type declaration or in the document body.
Anon-validating parser may, however, elect not to read parsableexternal entities (including theexternal subset), and does not have to honor the content model restrictions defined in element declarations and in attribute list declarations.
If the XML document depends on parsable external entities (including the specifiedexternal subset, or parsable external entities declared in theinternal subset), it should assertstandalone="no" in itsXML declaration. The validating DTD may be identified by usingXML Catalogs to retrieve its specifiedexternal subset.
In the example below, the XML document is declared withstandalone="no" because it has an external subset in its document type declaration:
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE people_list SYSTEM "example.dtd"><people_list/>
If the XML document type declaration includes any SYSTEM identifier for the external subset, it can not be safely processed as standalone: the URI should be retrieved, otherwise there may be unknown named character entities whose definition may be needed to correctly parse the effective XML syntax in the internal subset or in the document body (the XML syntax parsing is normally performedafter the substitution of all named entities, excluding the five entities that are predefined in XML and that are implicitly substitutedafter parsing the XML document into lexical tokens). If it just includes any PUBLIC identifier, itmay be processed as standalone, if the XML processor knows this PUBLIC identifier in its local catalog from where it can retrieve an associated DTD entity.
An example of a very simple external XML DTD to describe the schema of a list of persons might consist of:
<!ELEMENTpeople_list(person)*><!ELEMENTperson(name,birthdate?,gender?,socialsecuritynumber?)><!ELEMENTname(#PCDATA)><!ELEMENTbirthdate(#PCDATA)><!ELEMENTgender(#PCDATA)><!ELEMENTsocialsecuritynumber(#PCDATA)>
Taking this line by line:
people_list is a valid element name, and an instance of such an element contains any number ofperson elements. The* denotes there can be 0 or moreperson elements within thepeople_list element.person is a valid element name, and an instance of such an element contains one element namedname, followed by one namedbirthdate (optional), thengender (also optional) andsocialsecuritynumber (also optional). The? indicates that an element is optional. The reference to thename element name has no?, so aperson elementmust contain aname element.name is a valid element name, and an instance of such an element contains "parsed character data" (#PCDATA).birthdate is a valid element name, and an instance of such an element contains parsed character data.gender is a valid element name, and an instance of such an element contains parsed character data.socialsecuritynumber is a valid element name, and an instance of such an element contains parsed character data.An example of an XML file that uses and conforms to this DTD follows. The DTD is referenced here as an external subset, via the SYSTEM specifier and a URI. It assumes that we can identify the DTD with the relative URI reference "example.dtd"; the "people_list" after "!DOCTYPE" tells us that the root tags, or the first element defined in the DTD, is called "people_list":
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE people_list SYSTEM "example.dtd"><people_list><person><name>FredBloggs</name><birthdate>2008-11-27</birthdate><gender>Male</gender></person></people_list>
One can render this in an XML-enabledbrowser (such asInternet Explorer orMozilla Firefox) by pasting and saving the DTD component above to a text file namedexample.dtd and the XML file to a differently-named text file, and opening the XML file with the browser. The files should both be saved in the same directory. However, many browsers do not check that an XML document confirms to the rules in the DTD; they are only required to check that the DTD is syntactically correct. For security reasons, they may also choose not to read the external DTD.
The same DTD can also be embedded directly in the XML document itself as an internal subset, by encasing it within [square brackets] in the document type declaration, in which case the document no longer depends on external entities and can be processed in standalone mode:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><!DOCTYPE people_list [ <!ELEMENT people_list (person*)><!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)><!ELEMENT name (#PCDATA)><!ELEMENT birthdate (#PCDATA)><!ELEMENT gender (#PCDATA)><!ELEMENT socialsecuritynumber (#PCDATA)>]><people_list><person><name>FredBloggs</name><birthdate>2008-11-27</birthdate><gender>Male</gender></person></people_list>
Alternatives to DTDs (for specifying schemas) are available:
An XML DTD can be used to create aDenial-of-service attack by defining nested entities that expand exponentially, or by sending the XML parser to an external resource that never returns.[10]
For this reason,.NET Framework provides a property that allows prohibiting or skipping DTD parsing,[10] and recent versions ofMicrosoft Office applications (Microsoft Office 2010 and higher) refuse to open XML files that contain DTD declarations.