DITA has been designed to satisfy requirements for information
typing, semantic markup, modularity, reuse, interchange, and production
of different deliverable forms from a single source. These topics
provide an overview of the key DITA features and facilities that serve
to satisfy these requirements.
- DITA topics
- In DITA, a topic is the basic unit of authoring and reuse. All DITA
topics have the same basic structure: a title and, optionally, a body of content. Topics can be
generic or more specialized; specialized topics represent more specific information types or
semantic roles, for example, <concept>, <task>, <reference>, or
<learningContent>. See DITA topics for more information.
- DITA maps
- DITA maps are documents that organize topics and other resources into
structured collections of information. DITA maps specify
hierarchy and the relationships among the topics; they also
provide the context in which keys are defined and resolved. DITA
maps should have
.ditamap file
extensions. See DITA maps for more information.
- Information typing
- Information typing is the practice of identifying types of topics,
such as concept, reference, and task, to clearly distinguish between different types of
information. Topics that answer different reader questions (How ...? What is ...?) can
be categorized with different information types. The base information types provided by
DITA specializations (i.e., technical content, machine industry, and learning and
training) provide starter sets of information types that can be adopted immediately by
many technical and business-related organizations. See Information typing for more information.
- DITA linking
- DITA depends heavily on links. The purposes for which it
provides links include defining the content and organization of publication
structures (DITA maps), topic-to-topic navigation links and cross references, and
reuse of content by reference. All DITA links use the same addressing facilities,
either URI-based addresses or DITA-specific indirect addresses using keys and key
references. See DITA
linking for more information.
- DITA addressing
- DITA provides a number of facilities for establishing relationships
among DITA elements and between DITA elements and non-DITA resources. All DITA relationships use
the same addressing facilities irrespective of the semantics of the relationship established.
DITA addresses are either direct, URI-based addresses, or indirect key-based addresses. Within
DITA documents, individual elements are addressed by unique IDs specified on the common @id
attribute. DITA defines two fragment identifier syntaxes for addressing DITA elements, one for
topics and elements within maps and one for non-topic elements within topics. See DITA
addressing for more information.
- Content reuse
- The DITA @conref, @conkeyref, @conrefend, and related attributes
provide a mechanism for reuse of content fragments within DITA topics or maps. See Content
reuse for more information
- Conditional processing
- Attribute-based profiling, also known
as conditional processing or applicability, is the use of classifying
metadata that enables the filtering, flagging, searching, indexing,
and other processing based on the association of an element with one
or more values in a specific classification domain. See Conditional
processing for more information.
- Configuration
- A given DITA map or topic document is governed by a DITA document
type that defines the set of structural modules (topic or map types), domain modules, and
constraints modules that the map or topic can use. See Configuration for more information.
- 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. The
resulting specialization allows for the blind interchange of all conforming DITA content and 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.
See Specialization for more information.
- Constraints
- Constraint modules define additional
constraints for corresponding vocabulary modules in order to
restrict content models or attribute lists for specific element
types, remove extension elements from an integrated domain module,
or replace base element types with domain-provided extension
element types. Constraint modules do not and cannot change element
semantics, only the details of how element types can be used in the
context of a specific concrete document type. Because constraints
can make optional elements required, documents that use the
same vocabulary modules may still have incompatible constraints. Thus
the use of constraints can affect the ability for content from
one topic or map to be used directly in another topic or map. See
Constraints for more information.