Structural versus domain specialization

Structural specialization defines new types of structured information, such as new topic types or new map types. Domain specialization creates new markup that can be useful in multiple structural types, such as new kinds of keywords, tables, or lists.

Structural types define structures for modules of information, such as concept or task or reference, which often apply across subject areas (for example, a user interface task and a programming task may both consist of a series of steps). When new elements are introduced through structural specialization, the elements that contain the new elements must be specialized as well; and the new container elements must have their containers specialized in turn, all the way to the root element for the module (for example, the <topic> element or <map> element).

Domains typically define markup for a particular domain or subject area, such as programming, or hardware. Domain elements become available wherever their ancestor elements are allowed once the domains are integrated with the structural specializations in a document type.

Both structural specialization hierarchies and domain specialization hierarchies are “is a” hierarchies, in object-oriented terms, with each structural type or domain being a subclass of its parent. For example, a specialization of task is still a task; and a specialization of the programming domain is still concerned with programming.

Structural and domain hierarchies must share a common base module in order to be integrated together. For example, domains for use across topic types must ultimately be specialized off of elements in <topic>.

With the exception of the common base module, a domain cannot be specialized from a structural type. For example, a domain cannot be specialized from elements in <task>, only from the root structural modules for <topic> or <map>. This rule ensures that domains can be integrated and document types can be generalized predictably. The rule may be relaxed in future versions of DITA if a mechanism is added for tracking dependencies between structural and domain specializations in use by a document type.

Elements created by specialization are scoped by the name of the structural type or domain in which they were declared. For structural types, the name is the same as the root element: for example, task is the name of the structural type whose root element is <task>. For domains, the name is not shared with any element, but is assigned by the developer of the specialization. By convention, domain names end with "-d" and are kept short; for example, ui-d for the user interface domain and pr-d for the programming domain.