Specialization is the process of creating structural or domain vocabulary modules that provide new markup for specific requirements.
The essential aspect of specialization is that every element type or attribute defined in a vocabulary module must be based on and consistent with an element type or attribute defined in a more-general vocabulary module or in the base topic or map type.
This requirement ensures that any element, no matter how specialized, can always be mapped back to some known type and therefore understood and processed in terms of that known type. This ensures that all DITA documents, no matter how specialized, can always be processed in some way. That is, new markup should never break existing specialization-aware DITA processing.
Every element type exists in a specialization hierarchy that goes from the base module (topic or map) through any intermediate modules to the element itself.
For example, if you defined a specialization of
<myConcept>, its specialization hierarchy would be
<myConcept>. A processor given a
<myConcept> document would be able to process it as a
<myConcept> topic, a
<concept> topic, or a generic
<topic>, as appropriate.
The magic of specialization is the
@classattribute. The value of the class attribute is the specification of the specialization hierarchy for the element. The syntax of the
- A leading "-" or "+" character: "-" for structural types, "+" for domain types.
- One or more space-separated module/element-type pairs: "topic/p,""topic/body,""hi-d/i," etc.
- A trailing space character, which ensures accurate string matching on the last term in the hierarchy
<myConcept>topic type the
@classvalue would be
"- topic/topic concept/concept myConcept/myConcept "
<myConcept>element in the "myConcept" module, which specializes
<concept>from the "concept" module, which in turn specializes
<topic>from the "topic" module.
<myConcept>topic type defined a specialized body element, say
<myConceptBody>, then its
@classvalue would be:
"- topic/body concept/conbody myConcept/myConceptBody "
<myConcept>element, you would find these
<myConcept id="topicid" class="- topic/topic concept/concept myConcept/myConcept " > <title>My Concept</title> <myConceptBody class="- topic/body concept/conbody myConcept/myConceptBody " > </myConcept>
Note that these are attributes of element instances. While we tend to think of the
@class attribute as something that is set in DTDs or XSDs, that is merely a convenience.
What's really important is that the attributes are available to XML processors, which
will be the case whether they are defaulted in DTDs or specified explicitly in instances—the
two are identical to XML processors.
The magic of the
@class attribute is that specialized DITA documents can
"just work" when processed by general-purpose specialization-aware processors, such as
the DITA Open Toolkit.
One implication of this magic is that you can define new markup without needing to also implement all the different forms of processing that might be applied to that markup—it will just work. To the degree that your specialized markup doesn't require any specialized processing, then you will never need to implement new processing for it.
If your specialized markup does require specific processing, DITA-aware tools will tend to make adding that processing easier because they tend themselves to be modular. For example, the DITA Open Toolkit provides a general plugin mechanism that makes it easy to implement and deploy specialization-specific processing that extends the out-of-the-box processing using the smallest amount of custom code possible.