@classattribute rules and syntax
The specialization hierarchy of each DITA element is declared as the value of the
@class attribute. The
@class attribute provides a mapping from
the current name of the element to its more general equivalents, but it also can provide a
mapping from the current name to more specialized equivalents. All specialization-aware
processing can be defined in terms of
@class attribute values.
@class attribute tells a processor what general classes of elements the
current element belongs to. DITA scopes elements by module type (for example topic type,
domain type, or map type) instead of document type, which lets document type developers
combine multiple module types in a single document without
complicating transformation logic.
The sequence of values in the
@class attribute is important because it tells
processors which value is the most general and which is most specific.
This sequence is what enables both specialization aware processing and
@classattribute have the following syntax requirements:
These tokens provide a mapping for every structural type or domain in the ancestry of the specialized element. The specialization hierarchy for a given element type must reflect any intermediate modules between the base type and the specialization type, even those in which no element renaming occurs.
@class attribute is declared in an XML
grammar, it MUST be declared
with a default value. In order to support generalization round-tripping (generalizing
specialized content into a generic form and then returning it to the specialized form) the
default value MUST NOT be fixed. This
allows a generalization process to overwrite the default values that are defined by a
general document type with specialized values taken from the document being generalized.
A vocabulary module MUST NOT change
@class attribute for elements that it does not specialize, but simply
reuses by reference from more generic levels. For example, if
<guitask> use the
<p> element without specializing it, they MUST NOT declare mappings for it.
Authors SHOULD NOT modify the
@classattribute for the
The following code sample lists the DTD declaration for the
attribute for the
<!ATTLIST step class CDATA "- topic/li task/step ">
This indicates that the
<step> element is specialized from the
<li> element in a generic topic. It also indicates explicitly that
<step> element is available in a task topic; this enables
round-trip migration between upper level and lower level types without the loss of
@classattribute made explicit
The following code sample shows the value of the
@class attribute for the
<wintitle class="+ topic/keyword ui-d/wintitle ">A specialized keyword</wintitle>
@class attribute and its value is generally not surfaced in authored
DITA topics, although it might be made explicit as part of a processing operation.
@classattribute with intermediate value
The following code sample shows the value of a
@class attribute for an
element in the guitask module, which is specialized from
element is specialized from
<keyword> in the base topic vocabulary,
rather than from an element in the task module:
<windowname class="- topic/keyword task/keyword guitask/windowname ">...</windowname>
The intermediate values are necessary so that generalizing and specializing transformations
can map the values simply and accurately. For example, if task/keyword was
missing as a value, and a user decided to generalize this guitask up to a task topic, then
the transformation would have to guess whether to map to keyword (appropriate if task is
more general than guitask, which it is) or leave it as windowname (appropriate if task were
more specialized, which it isn't). By always providing mappings for more general values,
processors can then apply the simple rule that missing mappings must by default be to more
specialized values than the one we are generalizing to, which means the last value in the
list is appropriate. For example, when generalizing
<task>, if a
<p> element has no target value
<task>, we can safely assume that
not specialize from
<task> and should not be generalized.
Return to main page.
Standards Track Work Product
|Copyright © OASIS Open 2015. All Rights Reserved.||17 December 2015|