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, or new attributes such as conditional processing attributes.

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. Domain attributes (based off of props or base) become available wherever the props or base attributes are allowed.

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 or the specializable attributes in <topic>; domains for use across both topic types and map types must be specialized off of the elements or specializable attributes that are common to both types.

With the exception of the common base modules (topic and map), 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.

Elements and attributes 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. Attribute domains are a special case, typically named after the attribute being defined, with the addition of "-a".