Home
Non-normative information
This section contains non-normative information, including topics about new features in DITA 1.3 and migrating from DITA 1.2 to DITA 1.3.
Domains and constraints in the OASIS specification
This section provides a summary of the domains and constraints that are available as part of the OASIS specification, as well as a summary of how they are used.
Base document types: Included domains
This topic provides a summary of which domains are used in each of the base document types.

Specification URIs
Notices
Introduction to DITA 1.3
The Darwin Information Typing Architecture (DITA) specification defines a set of document types for authoring and organizing topic-oriented information, as well as a set of mechanisms for combining, extending, and constraining document types.
Architectural specification: All-inclusive edition
The architectural specification portion of the DITA specification outlines the framework of DITA. It contains an overview of DITA markup; addressing; processing; configuration, specialization, generalization, and constraints; as well as information about coding DITA grammar files.
Language reference: All-inclusive edition
The language reference portion of the DITA specification contains a topic for each DITA element. The topic defines the element, its inheritance hierarchy, and provides examples of usage. This portion of the DITA specification also includes information about DITA attributes.
Conformance
Conformance to the DITA specification allows documents and document types that are used with different processors or different versions of a processor to produce the same or similar results with little or no reimplementation or modification.
Acknowledgments
(Non-normative) Many members of the OASIS DITA Technical Committee participated in the creation of this specification and are gratefully acknowledged.
Non-normative information
This section contains non-normative information, including topics about new features in DITA 1.3 and migrating from DITA 1.2 to DITA 1.3.
- About the specification source
  The DITA specification is authored in DITA. It is a complex document that uses many DITA features, including key references (keyrefs), content references (conrefs), and controlled values set in a subject scheme map.
- Changes from previous versions
  The following topics outline the changes from earlier versions of DITA to the current version. Each version of the DITA specification is designed to be backwards-compatible with applications that conform to earlier versions of the DITA specification.
- File naming conventions
  The DITA OASIS Technical Committee uses certain conventions for the names of XML grammar files. We suggest using these conventions as a best practice to facilitate interchange of grammar files.
- Migrating to new versions of DITA
  DITA 1.3 is compatible with prior versions of the DITA specification; all valid DITA 1.0, 1.1, and 1.2 documents are valid DITA 1.3 documents. However, some changes to existing document-type shells and specializations might be needed in order to maintain the same behavior under DITA 1.3 or to take full advantage of new DITA 1.3 features.
- Considerations for generalizing <foreign> elements
  The <foreign> element can contain a mixture of DITA and non-DITA content. Non-DITA content that is contained within a <foreign> element cannot be generalized. However, the <foreign> element itself, as well as any DITA elements that it contains, can be generalized using normal rules.
- Element-by-element recommendations for translators: All-inclusive edition
  This topic contains a list of all OASIS DITA elements that are available in the edition. It includes recommendations on how to present the element type to translators, whether the element contents are likely to be suitable for translation, and whether the element has attributes whose values are likely to be suitable for translation. Examples of content that is not suitable for translation include code fragments and mailing addresses.
- DTD public identifiers
  Each document-type shell (.dtd file) or module component (.mod or .ent file) has a public identifier. The public identifier can reference either the latest version or a specific version of the document-type shell or module component.
- XML Schema catalog identifiers
  Each Schema document must be uniquely identified using a Uniform Resource Name (URN). Each Schema document has a version-independent as well as a version-specific URN.
- Domains and constraints in the OASIS specification
  This section provides a summary of the domains and constraints that are available as part of the OASIS specification, as well as a summary of how they are used.
  - Domains and constraints in the OASIS specification
    OASIS distributes grammar files for a set of domains and constraints.
  - Base domains: Where they are used
    This section provides a summary of which document types use each of the base OASIS domains.
  - Technical content domains and constraints: Where they are used
    This section provides a summary of which document types use each of the technical content domains and constraints.
  - Learning domains and constraints: Where they are used
    This section provides a summary of which document types use each of the learning and training domains and constraints.
  - Base document types: Included domains
    This topic provides a summary of which domains are used in each of the base document types.
  - Technical content document types: Included domains and constraints
    This topic provides a summary of which domains and constraints are used in each of the technical content document types.
  - Learning and training document types: Included domains and constraints
    This topic provides a summary of which domains and constraints are used in each of the learning and training document types.
- Processing interoperability considerations
  The DITA specification does not require processors to perform filtering, content reference resolution, key space construction, and other processing related to base DITA semantics in any particular order. This means that different conforming DITA processors might produce different results for the same initial data set and filtering conditions. DITA users and DITA implementers need to be aware of these potential differences in behavior when DITA content will be processed by different processors.
- Specialization design, customization, and the limits of specialization
  DITA specialization imposes certain restrictions. An inherent challenge in designing DITA vocabulary modules and document types is understanding how to satisfy markup requirements within those restrictions and, when the requirements cannot be met by a design that fully conforms to the DITA architecture, how to create customized document types that diverge from the DITA standard as little as possible.
Content models for learning and training package
For each element in the learning and training package, this section presents the content model and a list of parent elements that can contain that element.

Base document types: Included domains

This topic provides a summary of which domains are used in each of the base document types.

Table 1. Domain usage in base document types
Document type	Includes these domains	Does not include
base map	`@deliveryTarget` attribute Conref delayed resolution (map/topic) Hazard statement (map/topic) Highlighting (map/topic) Indexing (map/topic) Utilities (map/topic) Ditavalref (map) Map group (map)	Anything from technical content Anything from learning and training
base topic	`@deliveryTarget` attribute Hazard statement (map/topic) Highlighting (map/topic) Indexing (map/topic) Utilities (map/topic)	Base domains Conref delayed resolution (map/topic) Ditavalref (map) Map group (map) Anything from technical content Anything from learning and training