Elements are generalized by examining the class attribute. When a generalization process detects that an element belongs to one of the modules that is being generalized, the element is renamed to a more general form.
For example, the step element has a class attribute value of "- topic/li task/step ". If the task module is being generalized, the step element is renamed to its more general form from the topic module: li.
For specific concerns when generalizing structural types with dependencies on non-ancestor modules, see Generalization with cross-specialization dependencies.
While the tag name of a given element is normally the same as the type name of the last token in the class value, this is not required. For example, if a generalization process has already run on the element, the class attribute could contain tokens from two or more modules based on the original specialization. In that case, the element name could already match the first token or an intermediate token in the class attribute. A second generalization process could end up renaming the element again or could leave it alone, depending on the target module or document type.
Generalization and conref
To determine compatibility between a document instance and a target document type when resolving a conref reference, a generalization processor can use the domains and class attributes for the document instance and the domains attribute for the target document type to determine how to rename elements in the resolved instance. For each element type, a generalization processor:
- Iterates over the class attribute from specific to general, inspecting the vocabulary modules.
- Identifies the first vocabulary module that is both present in each document type, with a compatible set of constraints for that vocabulary module. If such a module is not found, the instance can only be generalized to a less constrained document type.