Configuration (Document type shells)

The DITA document type is defined entirely by the set of modules declared on the @domains attribute of the document's root element and by the values of the @class attributes of all the elements in the document. If the @domains attribute declares both structural and domain vocabulary modules, then the @domains attribute by itself serves to define the DITA document type. The information on the @domains and @class attributes is sufficient to implement all DITA-defined processing and constraint checking on documents (for example, determining if a referenced element in a content reference has a set of modules compatible with the modules used by the referencing element's document).

Thus, DITA does not require that conforming DITA documents have an associated DTD, XSD, or other formal document type definition as long as all required attributes are explicit in document instances. However, most DITA documents have an associated DTD or XML schema document by which the documents can be validated using normal XML processors and that can provide default values for the @domains and @class attributes, in particular. In addition, while the DITA specification only defines coding requirements for DTDs and XML schema documents, conforming DITA documents may use other document type constraint languages, such as RelaxNG or Schematron.

Per the coding requirements for DITA document types, document type shells are always implemented as a top-level file that only includes and configures vocabulary modules—they never directly define new element or attribute types.

Two document type shells define the same DITA document type if they integrate the same set of vocabulary and constraint modules. For example, a shell document type that is an unmodified copy of the OASIS-provided topic document type shell (topic.dtd or topic.xsd) defines the same DITA document type as the original but, because it is a distinct file, has a distinct system identifier (because it is not a replacement for the OASIS-provided shell but a copy of it, which must be stored in a different location) and must have a unique public identifier if a public identifier is associated with it. In particular, for document type shells not created by OASIS, the public identifier or URN for the document type shell must not indicate OASIS as the owner and should reflect the owner or creator of the document type shell. For example, if example.com creates a copy of the topic.dtd document type shell for its own use, an appropriate public identifier would be "-//example.com//DTD DITA Topic//EN", where "example.com" is the owner identifier component of the public identifier. An appropriate URN would be "urn:example.com:names:dita:xsd:topic.xsd".

While the DITA specification includes a starter set of document type shells for common combinations of modules, those document type shells are not mandatory.

DITA document type shells must follow the coding requirements defined in this specification. This ensures consistency of implementation and also serves to make the task of creating document type shells almost entirely mechanical.