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