There are times when a new structural or domain type appears not to fit into the existing hierarchy, based on the semantics of the existing types and the restrictions of the specialization process. In these cases there are a variety of options to consider.
The basic specialization mechanism used by the DITA document types can also be used for non-DITA document types in order to provide the same re-use, specialization, and interoperation benefits that one can get from the DITA document types, but restricted to the specific domain within which the new document types apply. Note that even if one uses the DITA-defined types as a starting point, any change to those base types not accomplished through specialization defines a completely new document type that has no meaningful or normative relationship to the DITA document types and cannot be considered in any way to be a conforming DITA application. In other words, the use of DITA specialization from non-DITA base types does not produce DITA-compliant document types.
However, given the substantial benefits of building from the common DITA base classes (including the ability to generalize to a common format, use of standards-compliant tools and processes, and reuse of content across document types through DITA maps and conref) there are some techniques to consider before complete departure from the DITA content architecture.
The first option to consider is to choose more generic base elements or attributes from the available set. There are generic elements in DITA available at every level of detail, from whole generic topics down to individual generic keywords, and the generic attribute base is available for attribute domain specialization.
For example, if you want to create a new kind of list but cannot usefully do so specializing from <ul>, <ol>, <sl>, or <dl>, you can create a new set of list elements by specializing nested <ph> elements. This new list structure will not be semantically tied to the other lists by ancestry, and so will require specialized processing to receive appropriate output styling. However, it will remain a valid DITA specialization, with the standard support for generalization, content referencing, conditional processing, and so forth.
DITA markup is organized into domain and structural type modules so that authoring groups can easily select the markup subset they require by creating a new document type shell. However, when an authoring group requires a subset of markup rules that does not follow the boundaries of the type modules (for example, global removal of certain attributes or elements), you can if necessary create a customized document type for the sake of enforcing these rules at authoring time, as long as the document types are validated using a standards-compliant document type at processing time.
A customized subset document type should be created without editing of the type modules. The document type shell can override entities in the module files, including attributes and content models, by providing a new definition of the entity before importing the module files.
Customized subset document types are not conformant with the DITA standard, and may not be supported by standards-conformant tools. For example, if you customize document types to remove the <xref> element, you may not be able to use off-the-shelf DITA editors to create your content.
While specialization can be used to adapt document types for many different authoring purposes, there are some authoring requirements that cannot be met through specialization, in particular, splitting or renaming attributes, or renaming elements through specialization without also specializing their containers.
In cases where structural and domain specialization of elements or attributes is not sufficient, and where the new document type can be straightforwardly and reliably transformed to a standard document type, the authoring group may be best served by a customized document type that is transformed to a standard document type as part of the publishing pipeline. For example, if an authoring group requires the <p> element to be spelled out as <paragraph>, the document type could be customized to change <p> to <paragraph> and then preprocessed to rename <paragraph> back to <p> before feeding the documents into a standard publishing process.
A customized document type should be created without editing of the type modules. The document type shell can override entities in the module files, including attributes and content models, by providing a new definition of the entity before importing the type module files.
Customized document types are not compliant with the DITA standard, and will not be supported by standards-compliant tools. Preprocessing can ensure compatibility with existing publishing processes, but does not ensure compatibility with DITA-supporting authoring tools or content management systems. However, when an implementation is being heavily customized in any case, a customized document types can help isolate and control the implications of non-standard design in a customized implementation.
Return to main page.
OASIS DITA Architectural Specification v1.1 -- Committee Draft 13 February 2007
Copyright © OASIS Open 2005, 2007. All Rights Reserved.