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.
A DITA implementation can consist of any combination of processing components that claim DITA awareness, custom vocabulary and constraint modules, or custom document-types shells.
For example, a DITA implementation might be a DITA-based authoring and publishing system within an enterprise; a task-specific product, such a DITA-aware XML editor or component management system; or a set of specialization and constraint modules that are packaged for integration with larger implementations.
Conforming DITA implementations MUST include a conformance statement that gives the version of the DITA specification that is supported. The conformance statement must include one of the following:
Implementations that include some (but not all) DITA features are considered conforming as long as all of the features that are included follow the requirements that are given in the DITA specification.
An implementation that does not include a particular optional feature MUST be prepared to interoperate with other implementations that do include the feature, though perhaps with reduced functionality. An implementation that does include a particular optional feature MUST be prepared to interoperate with other implementations that do not include the feature.
Organizations and individuals can impose additional restrictions on their own use of DITA that go beyond the requirements imposed by the DITA specification. These restrictions can include enforcement of the restrictions by their local processors, as long as the result continues to meet the requirements that are given in the DITA specification. For example, a user community can impose rules on how files must be named or organized, even if those rules go beyond the requirements given in the DITA specification.
<foreign> or <unknown> elements.If using non-DITA-conforming grammar files for conforming DITA documents, those grammar files MUST NOT be structured in a way that affects the ability of processors to process those documents. The use of non-conforming document types or schemas might impede interchange or interoperation of those documents with tools that expect or require the use of conforming DITA document types or schemas.
The conformance of processors can only be determined for DITA-aware processors. We define three types of DITA-aware processors.
@class and @domains attribute values.For example, a general-purpose processor that can process XML documents to produce a
particular output using user-created configurations or scripts is not itself DITA-aware.
However, that same processor packaged with a DITA-specific configuration or script would be
a DITA-aware processor. A script or configuration for this processor that only operates on
tag names as defined in specific DITA vocabulary modules would make the tool DITA aware but
not specialization aware. A script or configuration that operated on DITA
@class attribute values would be both DITA aware and specialization
aware.
In general, specialization-aware processors will be able to reliably process all conforming DITA documents, providing at least some default behavior for all DITA elements, while DITA-aware processors might only be able to reliably process documents that use the vocabulary modules that those processors support.
DITA-aware processors support the following functional areas:
A given processor might provide some or all of this function. For example, a DITA-aware editor that includes the ability to generate print versions of DITA documents represents both a final-form processor and an editing processor. Likewise, a content or component management system might tightly integrate final-form DITA processors. Each processor type might have different conformance requirements, even though the processors are part of a single product or package.
For processors that produce final form output, all features that are relevant to the type of processing that the processor performs MUST be implemented, with the exception of features that are vocabulary-specific. In particular, such processors MUST implement address resolution and content reference resolution. Such processors SHOULD implement filtering.
For example, a specialization-aware processor that produces final-form output need not
provide special presentation results for glossary entry topics, but it must implement
resolution of key-based references to glossary entry topics from
<keyword> or <term> elements, because
address resolution is both required and not vocabulary specific.
Processors that store, manage, or edit DITA documents might not implement specific features that would be required for final-form processing. However, such processors MUST enable the creation or storage of DITA documents that use all DITA features, even if the processor is not aware of the DITA semantics for those features.
For example, a DITA-aware editor need not provide specific support for creating or resolving content references, but it must allow, using normal XML editing methods, the creation and editing of content references. A content management system that supports map types that allow relationship tables but does not directly support relationship table processing must be able to store and manage conforming map documents that include relationship tables.