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.