This section outlines the requirements that must be met in order for documents, document types, vocabulary and constraint modules, and processors to be considered DITA conforming. This section also defines conformance-related terminology and categories.
Conformance to the DITA Specification allows documents and document types that are shared within and across organizations and used with different processors or different versions of a processor to produce the same or similar results with little or no reimplementation or modification.
The key words "must," "must not," "required," "shall," "shall not," "should," "should not," "recommended," and "optional" in the DITA Specification are to be interpreted as described in IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels.
The use of these key words and other conformance requirements increase the level of interoperability that is available between DITA conforming implementations. Their use is not meant to impose particular methods on implementers where the method is not required for interoperability.
The key words informative and non-normative identify content that is not normative. The DITA specifications include examples and other suggestions that are informative rather than normative. While informative information is often very helpful, it is never a binding part of the DITA specifications even when the example or other information is about a feature that is required. Unless it is clearly stated otherwise, examples and the appendices are always informative rather than normative.
Documents, document types, document type shells, vocabulary and constraint modules, and processors that implement the requirements given in the OASIS approved DITA Specification are considered conforming.
A "DITA implementation" may consist of any combination of processing components that claim DITA awareness, custom vocabulary and constraint modules, and custom document types shells.
Conforming DITA implementations must include a conformance statement that gives the version of the DITA Specification that is supported and lists the DITA features that are supported by the implementation in accordance with the requirements of that specification. Or, if it is clearer, the statement may say that the implementation includes all features except for a specific list of features that are not supported.
Implementations that include some DITA features, but not others, are considered conforming as long as all required features relevant to the implementation are included and all of the features that are included follow the requirements 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 are free to impose additional constraints on their own use of DITA that go beyond the requirements imposed by the DITA Specification, possibly including enforcement of the constraints by their local processors, as long as the result continues to meet the requirements given in the DITA Specification. For example, a given user community could impose rules on how files must be named or organized even if those rules go beyond the requirements given in the DITA Specification.
Processors that are not DITA-aware (as defined here) are not considered conforming, but may still be useful when working with DITA.
A document type is a conforming DITA document type if it consists only of conforming DITA vocabulary and constraint modules.
A DITA document type shell is a conforming shell if it represents a conforming DITA document type and conforms to the requirements for document type shells.
A vocabulary or constraint module is a conforming module if it conforms to the requirements for its module type.
The conformance of processors can only be determined for processors that claim to be "DITA aware".
DITA-aware merely means that the processor can handle documents conforming to at least one conforming DITA document type, as specified by the processor, but need not support any features not required by that document type.
Specialization-aware is a further, more-demanding class of processor that is able to handle any document specialized from some set of supported vocabulary modules and with, possibly, the required use of specific constraint modules.
The most complete DITA implementations are "fully DITA aware" processors that support all base vocabulary modules without constraint, which implies support for all non-vocabulary-specific DITA features, such as content references and key references.
A DITA-aware processor is a conforming DITA processor if it implements all required processing relevant to that processor for the vocabulary modules 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.
A DITA-aware processor is a conforming specialization-aware processor if it is a conforming DITA-aware processor and applies relevant processing to all DITA elements based on their @class and @domains attribute values.
While there are many possible processor types, DITA-aware processors can be classified generally into those that produce some sort of final form output from DITA documents (e.g., publishing systems and tools, such as the DITA Open Toolkit) and those that store, manage, or edit DITA documents (e.g., DITA-aware editors and content or component management systems). A given processor many provide any or all processing types.
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.
Processors that store, manage, or edit DITA documents may choose to 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.
Return to main page.
OASIS DITA Version 1.2 -- OASIS Standard, 1 December 2010
Copyright © OASIS Open 2005, 2010. All Rights Reserved.