Ruminations on the prohibition of <include> for DITA content

As presented in my Stage 2 proposal for <include>, it’s an error to reference XML content outside the context of <foreign>. The goal is to force users who wish to leverage reuse of DITA XML content to use @conref or @conkeyref instead.

I was talking to some of my colleagues about this, and they expressed serious concern about this provision. Many of our clients use CMS systems that do not enforce element-level referential integrity on conrefs and conkeyrefs. That is, if I have a @conref from Topic A to an element in Topic B, the CMS will probably prevent me from deleting Topic B, but it will not prevent me from deleting the target _element_ from Topic B. This limitation has led more than one of our clients to disregard @conref entirely, opting instead for XInclude, so that the CMS enforces referential integrity. Unfortunately, the use of XInclude circumvents DITA conref validation and thus it becomes possible to construct a document that is invalid after inclusions are resolved, but by and large the authoring tools discourage this, and it’s a tradeoff these clients gladly make. Of course, XIncludes are also not capabile of reference by key.

All of which has me reconsidering, a little, the prohibition on using <include> for DITA content. I’m a firm believer that the TC generally shouldn’t account too much for tooling limitations. At the same time, the near-universality of this limitation, at least in the CMS systems we commonly work with, is troubling. I’m curious about thoughts from others on the TC.

Chris

dita message