The constraints rules are intended to prevent (or at least discourage) the transclusion of less-constrained content into a more-constrained context. This is supposed to apply on an element level; that is that a less-constrained element should not be conreffed by a more-constrained one, regardless of the content models of other elements in the document. However, the current section on checking for constraint compatibility suggests that because it is impractical to check the content model of each element, all the constraints applying to the document type as a whole should be compared:
This is not widely practiced, if at all. But if it were practiced, this would prevent many groups' perfectly legal uses of conref (while the section says that processors "can" or "may" compare constraints in this way, the examples show that resolution is "prevented" rather than a warning being created). According to Eliot Kimber's helpful reply on my DITA-Users thread:
"The place where this tends to really surprise people is using generic topics to hold content intended to be conreffed from less-generic topics."
Another practical example where a document-level compatibility check would cause problems is for our team, where we conreffing a keyword from another topic type (that we use as a library topic) into a specialization of task. The two topics have different domains applied. The concept topic is using one constraint on CommonElements, and the specialized task topic is using a different constraint on CommonElements (removing fig, simpletable, and table). However, the keyword element itself is defined identically.
All a document-level constraint compatibility check can do is tell you that you might be conreffing a less-constrained element into a more-constrained one. As such, the result of such a check should only ever be a warning, not a blocking error as implied by the word "prevented" in the spec. I would question whether document-level compatibility checks are useful at all, and it seems that most toolmakers agree, as no-one seems to know of a tool that actually implements this. But if the suggestion of such a check must be kept in the spec, I would suggest:
- Describing the limitations of such a check
- Insisting that the strongest consequence of such a check should only ever be a warning, not a blocking error which could prevent perfectly legal and very common conref practices and hence limit interchange and increase the overhead of purchasing and updating tools.
Thanks in advance for considering this!
Regards,
Joe Pairman