Home
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.
Configuration, specialization, generalization, and constraints
The extension facilities of DITA allow existing vocabulary and constraint modules to be combined to create specific DITA document types. Vocabulary modules also can be specialized to meet requirements that are not satisfied by existing markup.
Constraints
Constraint modules define additional constraints for vocabulary modules in order to restrict content models or attribute lists for specific element types, remove certain extension elements from an integrated domain module, or replace base element types with domain-provided, extension element types.
Examples: Constraints
This section of the specification contains examples and scenarios. They illustrate a variety of ways that constraints can be used; they also provide examples of the DTD coding requirements for constraints and how constraints are integrated into document-type shells.
Example: Correct the constraint for the machinery task
For DITA 1.3, the OASIS DITA TC failed to update the constraint for the machinery task. In this scenario, an information architect corrects that oversight; she makes the (new for DITA 1.3) <tasktroubleshooting> element available in the body of the machinery task.

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.
- Introduction to DITA
  The Darwin Information Typing Architecture (DITA) is an XML-based architecture for authoring, producing, and delivering topic-oriented, information-typed content that can be reused and single-sourced in a variety of ways. While DITA historically has been driven by the requirements of large-scale technical documentation authoring, management, and delivery, it is a standard that is applicable to any kind of publication or information that might be presented to readers, including interactive training and educational materials, standards, reports, business documents, trade books, travel and nature guides, and more.
- DITA markup
  Topics and maps are the basic building blocks of the Darwin Information Typing Architecture (DITA). Metadata attributes and values can be added to DITA topics and maps, as well as to elements within topics, to allow for conditional publishing and content reuse.
- DITA addressing
  DITA provides two addressing mechanisms. DITA addresses either are direct URI-based addresses, or they are indirect key-based addresses. Within DITA documents, individual elements are addressed by unique identifiers specified on the @id attribute. DITA defines two fragment-identifier syntaxes; one is the full fragment-identifier syntax, and the other is an abbreviated fragment-identifier syntax that can be used when addressing non-topic elements from within the same topic.
- DITA processing
  DITA processing is affected by a number of factors, including attributes that indicate the set of vocabulary and constraint modules on which a DITA document depends; navigation; linking; content reuse (using direct or indirect addressing); conditional processing; branch filtering; chunking; and more. In addition, translation of DITA content is expedited through the use of the @dir, @translate, and @xml:lang attributes, and the <index-sort-as> element.
- Configuration, specialization, generalization, and constraints
  The extension facilities of DITA allow existing vocabulary and constraint modules to be combined to create specific DITA document types. Vocabulary modules also can be specialized to meet requirements that are not satisfied by existing markup.
  - Overview of DITA extension facilities
    DITA provides three extension facilities: configuration, constraint, and specialization. In addition, generalization augments specialization.
  - Configuration
    Configuration enables the definition of DITA document types that include only the vocabulary modules that are required for a given set of documents. There is no need to modify the vocabulary modules. Configurations are implemented as document-type shells.
  - Specialization
    The specialization feature of DITA allows for the creation of new element types and attributes that are explicitly and formally derived from existing types. This facilitates interchange of conforming DITA content and ensures a minimum level of common processing for all DITA content. It also allows specialization-aware processors to add specialization-specific processing to existing base processing.
  - Generalization
    Generalization is the process of reversing a specialization. It converts specialized elements or attributes into the original types from which they were derived.
  - Constraints
    Constraint modules define additional constraints for vocabulary modules in order to restrict content models or attribute lists for specific element types, remove certain extension elements from an integrated domain module, or replace base element types with domain-provided, extension element types.
    - Overview of constraints
      Constraint modules enable information architects to restrict the content models or attributes of OASIS-defined DITA grammars. A constraint is a simplification of an XML grammar such that any instance that conforms to the constrained grammar also will conform to the original grammar.
    - Constraint rules
      There are certain rules that apply to the design and implementation of constraints.
    - Constraints, processing, and interoperability
      Because constraints can make optional elements required, documents that use the same vocabulary modules might have incompatible constraints. Thus the use of constraints can affect the ability for content from one topic or map to be used in another topic or map.
    - Weak and strong constraints
      Constraints can be classified into two categories: Weak and strong. This classification determines whether processors enforce strict compatibility during @conref or @conkeyref resolution.
    - Conref compatibility with constraints
      To determine compatibility between two document instances, a conref processor checks the @domains attribute to confirm whether the referencing document has a superset of the vocabulary modules in the referenced document. If one or both of the document instances are constrained, the conref processor checks to confirm the compatibility of the constraints.
    - Examples: Constraints
      This section of the specification contains examples and scenarios. They illustrate a variety of ways that constraints can be used; they also provide examples of the DTD coding requirements for constraints and how constraints are integrated into document-type shells.
      - Example: Redefine the content model for the <topic> element
        In this scenario, an information architect for Acme, Incorporated wants to redefine the content model for the topic document type. She wants to omit the <abstract> element and make the <shortdesc> element required; she also wants to omit the <related-links> element and disallow topic nesting.
      - Example: Constrain attributes for the <section> element
        In this scenario, an information architect wants to redefine the attributes for the <section> element. He wants to make the @id attribute required and omit the @spectitle attribute.
      - Example: Constrain a domain module
        In this scenario, an information architect wants to use only a subset of the elements defined in the highlighting domain. She wants to use <b> and <i,> but not <line-through>, <overline>, <sup>, <sup>, <tt>, or <u>. She wants to integrate this constraint into the document-type shell for task.
      - Example: Replace a base element with the domain extensions
        In this scenario, an information architect wants to remove the <ph> element but allow the extensions of <ph> that exist in the highlighting, programming, software, and user interface domains.
      - Example: Apply multiple constraints to a single document-type shell
        You can apply multiple constraints to a single document-type shell. However, there can be only one constraint for a given element or domain.
      - Example: Correct the constraint for the machinery task
        For DITA 1.3, the OASIS DITA TC failed to update the constraint for the machinery task. In this scenario, an information architect corrects that oversight; she makes the (new for DITA 1.3) <tasktroubleshooting> element available in the body of the machinery task.
- Coding practices for DITA grammar files
  This section collects all of the rules for creating modular DTD, RELAX NG, or XML Schema grammar files to represent DITA document types, specializations, and constraints.
- Technical content specializations
  This section contains information about the technical content specializations. It includes a summary of the document types and domains, as well as information about how the technical content specializations support authoring troubleshooting information.
- Learning and training specializations
  The section contains information about the learning and training specializations: Challenges faced by developers of instructional content; use cases; objectives of the specializations; information about the reusable learning-objects approach to learning and training content; summary of the topic types and domains; and more.
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.
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.

Example: Correct the constraint for the machinery task

For DITA 1.3, the OASIS DITA TC failed to update the constraint for the machinery task. In this scenario, an information architect corrects that oversight; she makes the (new for DITA 1.3) <tasktroubleshooting> element available in the body of the machinery task.

Note: This example assumes that the information architect has already implemented her own document-type shell for the machinery task information type.

She makes a copy of the machineryTaskbodyConstraint.mod file and renames it correctedMachineryTaskbodyConstraint.mod.

She modifies the correctedMachineryTaskbodyConstraint.mod file to declare the entity for the <tasktroubleshooting> element and make it available at the correct place within the task body. (Her modifications are highlighted in bold below.)

<!ENTITY taskbody-constraints
  "(topic task+taskreq-d machineryTaskbody-c)"
>
<!ENTITY % prelreqs                                        "prelreqs">
<!ENTITY % context                                         "context">
<!ENTITY % section                                         "section">
<!ENTITY % steps                                           "steps">
<!ENTITY % steps-unordered                                 "steps-unordered">
<!ENTITY % steps-informal                                  "steps-informal">
<!ENTITY % result                                          "result">
<!ENTITY % tasktroubleshooting                             "tasktroubleshooting">
<!ENTITY % example                                         "example">
<!ENTITY % closereqs                                       "closereqs">


<!ENTITY % taskbody.content
              "((%prelreqs; |
                 %context; |
                 %section;)*,
                (%steps; |
                 %steps-unordered; |
                 %steps-informal;)?,
                (%result;)?,
                (%tasktroubleshooting;)?,
                (%example;)*,
                (%closereqs;)?)"

She updates her company-specific document-type shell to integrate the updated constraint.
After updating the catalog.xml file to include the new constraints file, her work is done.