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
The following topics outline the changes from earlier versions of
DITA to the current version. Each version of the DITA specification is designed to
backwards-compatible with applications that conform to earlier versions of the 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
document-type shells and specializations might be needed in order to maintain the
under DITA 1.3 or to take full advantage of new DITA 1.3 features.
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.
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,
the element contents are likely to be suitable for translation, and whether the element
attributes whose values are likely to be suitable for translation. Examples of content
not suitable for translation include code fragments and mailing addresses.
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
document-type shell or module component.
The DITA specification does not require processors to perform filtering, content
reference resolution, key space construction, and other processing related to base
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.
DITA specialization imposes certain restrictions. An inherent challenge in designing
DITA vocabulary modules and document types is understanding how to satisfy markup
within those restrictions and, when the requirements cannot be met by a design that
conforms to the DITA architecture, how to create customized document types that diverge
DITA standard as little as possible.