DITA specialization imposes certain restrictions. An inherent challenge in designing DITA vocabulary modules and document types is understanding how to satisfy markup requirements within those restrictions and, when the requirements cannot be met by a design that fully conforms to the DITA architecture, how to create customized document types that diverge from the DITA standard as little as possible.
When markup requirements cannot be met within the DITA architecture, there still might be an interest in using DITA features and technology, or a business need for interoperability with conforming DITA documents and processors. In this case, the solution is to create customized document types. Customized document types are document types that do not conform to the DITA standard. To reduce the cost of producing conforming documents from non-conforming documents, custom document types should minimize the extent to which they diverge from the DITA standard.
<foreign> or <unknown> elementsRemember that customized document types do not conform to the DITA standard, and thus are not considered DITA. In many of the cases above, it is possible to define document types that conform to the DITA standard. Explore this fully before developing customized document types.
Conforming DITA grammar files are modular, which facilitates exchange of vocabulary modules and constraints and simplifies the process of assembling document type shells. In some cases there might be a reason to avoid the modular approach and use an optimized document type composed of a single file (or a smaller number of files). For example, this could be advantageous in situations where validation occurs over a network.
In an optimized DTD, entities might also be resolved to further optimize processing or validation. This could speed up processing for environments that process and validate large numbers of DITA maps and topics.
An optimized document type will still allow for the creation of conforming DITA content that follows all other rules in the DITA specification. In these cases it is still possible to create a document type that conforms completely to standard DITA coding practices. Maintaining a conforming copy ensures that the optimized document type is still conforming to the standard, and might also ease interchange with tools that expect conforming document types.
When the relaxed content models for DITA elements are inappropriately open for authoring purposes, document type shells can remove undesireable domains or use constraint modules to restrict content models. If content models are not relaxed enough, and markup requirements include content models that are less constrained than those defined by DITA, custom document types might be the only option.
Customized document types do not conform to the DITA standard. Preprocessing can ensure compatibility with existing publishing processes, but it does not ensure compatibility with DITA-supporting authoring tools or content management systems. However, when an implementation is being heavily customized, a customized document type can help isolate and control the consequences of non-standard design.
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> for authoring
purposes. Such documents then could be preprocessed to rename
<paragraph> back to <p> before they are fed
into a standard DITA publishing process.
Because DITA document types are designed to enable constraints, such customized documents can still take advantage of existing override schemes. While still not valid DITA, a document type shell could be set up that implements local requirements (such as adding global CMS-defined attributes), and then imports an otherwise valid document type shell. This helps isolate non-compliant portions of the document type, while reusing as much as possible of the original DITA grammar.
Requirements for new markup often appear to be incompatible with DITA architectural rules or existing markup, especially when mapping existing non-DITA markup practice to DITA, where the existing markup might have used structures that cannot be directly expressed in DITA. For example, you might need markup for a specialized form of list where the details are not consistent with the base model for DITA lists.
In this case you have two alternatives, one that conforms to DITA and one that does not.
Specializing from more generic base elements, such as defining a list using specializations
of <ph> or <div>, while technically
conforming, might still impede interchange of such documents. Generic DITA processors will
have no way of knowing that what they see as a sequence of phrases or divisions is really a
list and should be rendered in a manner similar to standard DITA lists. However, your
documents will be reliably interchangeable with conforming DITA systems.
Defining non-conforming markup structures means that the resulting documents are not conforming DITA documents. They cannot be reliably processed by generic DITA-aware processors or interchanged with other DITA systems. However, as long as the documents can be transformed into conforming DITA documents without undue effort, interchange and interoperation requirements can be satisfied as needed. For example, a content management system could add its own required markup for management metadata, but strip the metadata when delivering content to conforming DITA processors.
Note that even if one uses the DITA-defined types as a starting point, any change to those base types not accomplished through specialization or the constraint feature defines a completely new document type that has no normative relationship to the DITA document types, and cannot be considered in any way to be a conforming DITA application. In particular, the use of DITA specialization from non-DITA base types does not produce DITA-conforming vocabularies.
Most DITA element types have relaxed content models that are specifically designed to allow a wide set of options when specializing from them. However, some DITA element types do impose limits that might not be acceptable or appropriate for a specific markup application. In this case, consider specializing from a more generic base element or attribute.
Generic elements are available in DITA at every level of detail, from whole topics down to
individual keywords, and the generic @base attribute 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 <div> elements. This new list
structure will require specialized processing to generate appropriate output styling,
because it is not semantically tied to the other lists by ancestry. Nevertheless, it will
remain a valid DITA specialization, with the standard support for generalization, content
referencing, conditional processing, and more.
<topic> are generic enough to support
almost any structurally-valid DITA specialization:<topic><section><p><fig><ul>, <ol>,
<dl>, <sl>,
<simpletable><ph><text><keyword><data><foreign><unknown><bodydiv><sectiondiv><div>@props@baseWhenever possible, specialize from the element or attribute that is the closest semantic match.