Creating a specialization
When choosing an element to specialize, look for a base element that:
- Has a more general meaning that also applies to your content
- Can accommodate the substructure of your content
Within the Toolkit dtd directory, create a DTD module in which the DTD elements derive from the elements of an existing DTD module.
Processing a specialization
If you do not modify the Toolkit processing, the Toolkit built-in generalization process automatically promotes your specialized element to the base element from which it derives, and processes it the same way it processes the base element.
If you want to modify the default processing, create a new XSLT script in the Toolkit xsl directory that imports the base XSLT script and provides special formatting for your specialized element.
In your Ant build script, add an "args.xsl" parameter to cause your new XSLT script to be used instead of the default.
Limits of specialization
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, consider the following options before abandoning the idea of specialization:
-
Specialize from generic elements. 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. Always specialize from the semantically closest match whenever possible.
-
Create a customized subset document type. Customized subset document types are not compliant with the DITA standard, and may not be supported by standards-compliant tools. However, they can help limit the quantity and mitigate the consequences of non-standard design in a customized implementation. Your customized document type can be transformed to a standard document type as part of the publishing pipeline. For example, if an authoring group requires additional metadata attributes, and finds authoring multiple metadata axes in one attribute (otherprops) unusable, the document type could be customized to add metadata attributes and then preprocessed to push those values into otherprops before feeding the documents into a standard publishing process. Customized document types are not compliant with the DITA standard and will not be supported by standards-compliant tools. However, a customized document type can help isolate and control the implications of non-standard design in a customized implementation.