The class attribute

Each element declared in the DITA architecture has a class attribute. This attribute provides a mapping between the element's current name and its more general equivalents. The more specialized the element type, the longer its class attribute value.

For example, the class attribute for the task topic type's step element is:

<!ATTLIST step         class  CDATA "- topic/li task/step ">

This tells us that the step element is equivalent to the li element in a generic topic. It also tells us that step is equivalent to a step in a task topic, which we already knew, but it's worth noting this in the attribute because it enables round-trip migration between upper level and lower level types without loss of information. For example, if a user runs a "generalize" transform that maps all elements to their first class value, but preserves their content and attribute values, then the user can follow it up with a "specialize" transform that maps all elements to their last class value (preserving content and attribute values), and provide a full round trip for all content between the two document types, using nothing but two generic transforms and the information in the class attribute.

The class attribute tells a processor what general classes of elements the current element belongs to. It's something like an architectural forms attribute, except that it contains multiple mappings in a single attribute, instead of one mapping per attribute. Also, DITA scopes values by module type (for example topic type, domain type, or map type) instead of document type, which lets us combine multiple topic types in a single document without complicating transform logic.

Combining the mappings into a single attribute gives us the following benefits:

preservation of sequence: you can tell by looking at the order of values which one is the most general and which one is the most specific. This is especially important for "specializing" transforms, where you can apply a general rule that says: if the element doesn't have a mapping to the target topic type, simply use the last value of the class attribute (and assume that the specialized topic type is reusing some general element declarations, which only have mappings for the level at which they were declared).
mapping persistence through migration: when you migrate to a higher-level element, you can preserve its more specialized history in the class attribute. If you were declaring a new attribute for each new mapping (as in architectural forms), then when you migrated to the higher-level type the declaration for the mapping attribute would disappear, and roundtripping would be considerably more problematic.