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.
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.
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.
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:
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).
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.
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.
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.