Text of the draft DITA 2.0 conformance statement

An implementation is a conforming implementation of DITA if the implementation meets the conditions in Section X.1. A document is a conforming DITA document if the document meets the conditions in Section X.2.

Conformance to the DITA specification allows documents and document types that are used with different processors to produce the same or similar results with little or no reimplementation or modification. Conformance also allows DITA specializations to work with any conforming DITA application, with at least the same level of support available to unspecialized documents.

X.1 Conformance of DITA implementations

The DITA specification defines several core features, as summarized in the following list. Any implementation that supports a feature MUST conform to all rules laid out in the section that describes the feature.

Specialization-based processing, as described in X.
Resolving links to elements in DITA documents, as described in section X.
Resolving @keyref attributes to a key defined in a map, as described in section X.
Resolving @keyref attributes across key scopes, as described in section X.
Pulling content references, as described in section X and X.
Pushing content references, as described in section X.
Resolving conditional processing based on DITAVAL documents, as described in section X.
Resolving branch filtering markup, as described in section X.
Resolving @chunk attributes, as described in section X.

In addition, several base DITA elements provide normative rules regarding how to render those elements. Applications that render these elements MUST support some way to render these elements as described.

<element>, as described in X
<element>, as described in X
<element>, as described in X

Conforming DITA implementations SHOULD include a conformance statement that gives the version of the DITA specification that is supported, indicate if all features from the list above are supported, and indicate that all normative rendering rules are supported.

If only a subset of features is supported, implementations SHOULD indicate which features are (or are not) supported. If an implementation supports rendering DITA elements but does not render all elements as described above, that application SHOULD indicate which elements are (or are not) supported.

Not all DITA features are relevant for all implementations. For example, a DITA editor that does not render content references in context does not need to conform to rules regarding the @conref attribute. However, any application that renders content references MUST conform to rules in Section X.X Content references.

Implementations that support only a subset of DITA features are considered conforming as long as all supported features follow the requirements that are given in the DITA specification. An implementation that does not support a particular feature MUST be prepared to interoperate with other implementations that do support the feature.

X.2 Conformance of DITA documents

A document conforms with the DITA standard if it meets all of the following conditions.

A DITA document that refers to document type shells distributed by OASIS MUST be valid according to both the grammar files and any assertions provided in the language reference.
If a DITA document refers to a custom document type shell, that shell MUST also conform to the rules laid out in X.X.X.X Rules for document-type shells.
If a DITA document's custom document type shell includes constraints, that shell MUST also conform to the rules laid out in X.X.X.X Constraint rules
If a DITA document uses specialized elements or attributes, those elements or attributes MUST also conform to the rules laid out in X.X.X Specialization rules for element types, X.X.X Specialization rules for attributes, and X.X.X Class attribute rules and syntax.

dita message

Conformance

X.1 Conformance of DITA implementations

X.2 Conformance of DITA documents