Conformance

4.1 Conformance of DITA implementations

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:

• List of the DITA features that are supported by the implementation in accordance with the requirements of the DITA specification
• Statement that the implementation includes all features except for a specific list of features that are not supported in accordance with the requirements of the DITA specification

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.

4.2 Conformance of DITA documents

A conforming DITA document is a document that meets all of the following criteria:

• It is a well-formed XML document.
• Its elements either are DITA elements or non-DITA elements that are contained within <foreign> or <unknown> elements.
• Its content conforms to all DITA requirements for element content and attribute values.

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.

4.3 Conformance of DITA processors

The conformance of processors can only be determined for DITA-aware processors. We define three types of DITA-aware processors.

DITA-aware processor

A processor that implements all required processing relevant to the vocabulary modules that it claims to support. A DITA-aware processor MUST support at least one map or topic type, whether defined by the DITA standard or defined as a custom vocabulary module.

Specialization-aware processor

A DITA-aware processor that can handle any document specialized from some set of DITA vocabulary modules, though it might not be able to support all base topic or map elements.

Fully aware processor

A DITA-aware processor that unconditionally supports all base vocabulary modules, which implies support for all non-vocabulary-specific DITA features, such as content references and key references. It applies relevant processing to all DITA elements based on their @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:

Production of output

The production of final form output from DITA documents. Examples of processors that perform this function are publishing systems and tools, such as the DITA Open Toolkit.

Editing, managing, and storage

The editing, managing, and storage of DITA documents. Examples of processors that perform this function are authoring tools and component content management systems (CCMS).

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.