Conformance

The DITA specification is an "application standard", meaning that it defines rules not just for data representation or manipulation but for all the components that make a working documentation support system:

The data that forms the primary input to the application, represented as XML documents conforming to the XML syntax and content rules defined by the DITA specification.
The formally-specific constraints to which the data must conform, represented as XML document type declarations, XML schema definition documents (XSD), or other XML document constraint mechanisms as defined by the DITA specification or conforming the DITA-defined rules for constructing new conforming constraint specifications.
The data processors that act on the data in terms of its DITA-defined characteristics in order to produce some useful service or result from that data. Such processors include editors that support authoring and modifying DITA documents, content management systems that manage DITA documents through their life cycles, and renderers that produce new deliverables from DITA documents, such as HTML pages or paginated PDF documents. The range of possible processor is largely unbounded.

Each of these aspects of a complete "DITA application" has different conformance requirements reflecting the nature of the aspects themselves and the degree to which conformance can be objectively tested.

Because a DITA application is not necessarily (or normally) a monolithic black box but rather composed of many components from many sources, the question of whether or not a given "DITA application" is or is not a "conforming DITA application" is answerable only by considering the degree to which each of the individual components—the documents, their governing document type definitions, and the processors that act on them—conform to the specific rules of the DITA specification as defined in this clause.

DITA is, first and foremost, a data interchange standard, driven by the overall requirement to define standards and methods for document representation that enable the most efficient interchange of documents across user communities and enterprises, among processors, and from the present to the future. This means that the most important aspect of conformance is conformance of documents and their constraint specifications. Without conformance of documents interchange is impossible. For most users of DITA the expected life cycle of any given document will often be measured in decades while processor components tend to have life spans of years or months. In addition, what constitutes a useful or correct processor is much more in the purview of the user who needs the processing than it is in the purview of the DITA standard. The DITA specification defines conformance rules for processors in order to ensure consistent behavior for those aspects of DITA processing that must be invariant as well as to provide a baseline for processing expectations for those aspects of DITA processing that may vary or that cannot be usefully standardized.

These conformance requirements apply to documents and processors. Users of DITA are free to impose additional constraints on their own use DITA as a matter of local policy, including building enforcement of those constraints into their local tool sets. For example, a given user community could impose rules on how files must be organized.

Conformance of Documents

A document is a conforming DITA document if it is syntactically valid with respect to a conforming XML document type declaration (DTD) or XML schema document (XSD) and otherwise meets all content and structure requirements defined by the DITA specification.

Conformance of Document Types and Specialization Modules

A document type is a conforming DITA document if it meets all the syntactic and organizational requirements for DITA shell document types as defined in the DITA Architecture Specification.

A specialization module is a conforming DITA specialization if it meets all of the syntactic and organizational requirements for DITA specialization modules as defined in the DITA Architecture Specification.

Conformance of DITA-Aware Processors

The DITA specification defines different classes of processing features, distinguished by the degree to which processors can vary from the rules defined by the DITA specification. The feature classes are:

required and invariant: Features that conforming processors must implement and for which the behavior of processors must be exactly as defined in the DITA specification. This classification applies primarily to address resolution behavior, where a given address must always resolve to the same object for the same input data set.
required but variable: Features that conforming processors must implement and for which the effective result must be consistent with rules as defined in the DITA specification but for which the specific expression may vary. For example, any implementation of the content reference feature must reflect the same effective result for the same input data set but the way that effective result is provided can vary.
For example, the content reference could be implemented by pre-process that replaces the reference by the referenced content or by a process that generates the functional equivalent of the content reference in the target output (e.g., a transclusion instruction in a Wiki page).
processor-defined with defaults: Features for which processors are free to define the resulting behavior but for which the DITA specification defines a default that all conforming processors of the relevant processor type must provide. These features are primarily formatting defaults for elements where a default presentation is natural or expected, such as paragraphs, lists, and tables. Note that applications are not required to make the DITA-defined default their default. Applications are only required to provide an appropriate set of options or configuration that will provide the DITA-defined defaults.
The reason for requiring the ability to produce the default behavior is to enable the fair and accurate comparison of DITA applications in terms of the behaviors defined in the DITA specification. It is assumed that any processor sophisticated enough to do useful DITA processing is also sophisticated enough to produce both a special-purpose result as well as the DITA-defined default result.

An application for a specific use domain might, for example, define default formatting behaviors that are significantly different from the DITA-defined defaults. The primary concern is one of appropriate matching of user expectations to processor behavior. A user using a generic DITA processor for the first time will likely expect to see the DITA-defined defaults, which a user using a domain-specific application would likely expect defaults reflecting the normal practice in that domain. For example, an application specifically for legal information would provide different default presentation from an application for technical documentation.
procesor-defined without defaults: Features for which processors are free to define the resulting behavior and for which the DITA specification defines no required default.
The DITA specification may define example or suggested behaviors for these features but such suggestions are informative, not normative.

The possible range of DITA-aware processors is inherently unbounded: it is impossible to predict how someone might usefully process DITA documents. However, there is a recognized set of typical DITA processors. The set of features for which a given processor must provide conforming processing is dependent on the type of processing the processor performs: an XML-to-XML transformation processor does not need to implement formatting requirements nor does a content management system. Likewise, a renderition processor may never need to do content reference processing because it will have been done by another component. Thus conformance of processors is defined in terms of processor types and the features relevant to each processor type. Note also that given software component may embody more than one processor type. For example, a graphical DITA-aware editor may constitute an editing processor, an XML-to-XML processor, and a rendition processor.

The processor types used for DITA conformance definition are:

Source-to-Source Transformer: A processor that takes as input one or more DITA documents and produces as output non-final-form XML documents. The resulting documents may or may not be themselves conforming DITA documents. Source-to-source transformers may be standalone tools or may be inseparable components of tools in other categories.
DITA editor: A interactive application that enables the creation and modification of conforming DITA documents.
Renderer: A processor that takes as input one or more conforming DITA documents and produces as output final-form renderings of those documents, such as HTML pages, paginated PDF, compiled online help, etc. Most simply, a DITA renderer is a processor that is directly responsible for producing a visual, aural, tactile, or interactive result from DITA content, either by providing the rendition directly or by providing direct input to the rendition delivery system (e.g., providing HTML content to a Web browser or typesetting commands to a pagination system). A renderer always either incorporates a source-to-source transform within itself or uses the output of a standalone source-to-source transformer.
Information management system: A processor that stores and manages DITA documents in a way that takes advantage of DITA-specific aspects of the data in order to facilitate the management of those documents through a development or delivery process. Such systems may be content management systems that support authoring workflows or they may be retrieval systems that support delivery workflows.

Not all rendition requirements, defaults, and suggestions are relevant to all possible rendered outputs. The DITA specification uses the following rendition types in defining rendition requirements and suggestions:

HTML-based interactive media: Renditions that use HTML markup as the primary representation, intended to be viewed through Web browsers or similar online, interactive systems.
paged media: Renditions that produce images of physical pages intended for printing on paper.
Embedded "constrained format" help: Help for use with highly constrained delivery environments such as mobile phones and printer consoles.
aural: Renditions that are intended for aural consumption by human listeners.
interactive: Renditions that include interactive behavior as a primary aspect of their presentation, such as as military Interactive Electronic Technical Manuals or interactive learning applications.

General Processor Conformance

All conforming DITA processors must be specialization aware such that they are able to process any valid DITA document regardless of the details of its governing document type.

In practice this means that all conforming DITA processors must be able to directly or indirectly bind processing to elements based on the value of elements' class= attribute. Indirect recognition of class= values may be via a generalization preprocess by which specialized elements are transformed into base types recognized by the processor.

All conforming DITA documents must include the DITAArchVersion= attribute in the DITA Architecture namespace "http://dita.oasis-open.org/architecture/2005/". Applications may but are not required to process any documents that do not exhibit the DITAArchVersion= attribute. Applications should issue appropriate warnings when processing as DITA documents that do not exhibit the DITAArchVersion= attribute.