Structural versus domain specializationStructural 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".
TOC: Architectural Specification 1.1
Parent topic: DITA specialization
Previous topic: Why specialization?
Next topic: Specializing foreign or unknown content
|
