Constraints, processing, and interoperability

Because constraints can make optional elements required, documents that use the same vocabulary modules might have incompatible constraints. Thus the use of constraints can affect the ability for content from one topic or map to be used in another topic or map.

A constraint does not change basic or inherited element semantics. The constrained instances remain valid instances of the unconstrained element type, and the element type retains the same semantics and @class attribute declaration. Thus, a constraint never creates a new case to which content processing might need to react.

For example, a document type constrained to require the <shortdesc> element allows a subset of the possible instances of the unconstrained document type with an optional <shortdesc> element. Thus, the content processing for topic still works when <topic> is constrained to require a short description.

A constrained document type allows only a subset of the possible instances of the unconstrained document type. Thus, for a processor to determine whether a document instance is compatible with another document type, the document instance MUST declare any constraints on the document type.

For example, an unconstrained task is compatible with an unconstrained topic, because the <task> element can be generalized to <topic>. However, if the topic is constrained to require the <shortdesc> element, a document type with an unconstrained task is not compatible with the constrained document type, because some instances of the task might not have a <shortdesc> element. However, if the task document type also has been constrained to require the <shortdesc> element, it is compatible with the constrained topic document type.