Constraint domain tokens can disable conref based on context
This was a core part of the constraint definition in DITA 1.2, and was designed to ensure you couldn't just use content reference to bypass some (presumably important) constraint.
And I'm pretty sure this is where we start to veer into fantasy.
DITA 1.2 defined constraint modules. They're important, even critical. As with every new module,
the specification defined a syntax for the
@domains token. OK. The syntax says your
token MUST contain
-c, which tells you a constraint domain is in use. But …
it doesn't tell you what element is constrained, or how. It can't be that specific.
So what practical use does this serve?
Here's the theory: I might have one document type that says "Don't allow
in my list items". I might pull a list item from your document type that does allow
<p> in list items. THIS! SHALL! NOT! PASS! (all of our conref processing
rules!) Because if it did, then I'd be pulling in something that would not otherwise be
valid in my document. And that would make me a bad person. We do not want that to happen to
you! So DITA tools must prevent me (and you) from becoming such a bad
So: with the mandated
@domains token, a processor will find the token in my
document, identify that "Uh oh, I've got a constraint the other document doesn't have", and refuse
to resolve the content reference.
Except that like above … it's an unlikely scenario. If I've gone to the trouble to constrain an element in my document, I'm extremely unlikely to pull freely from one that doesn't constrain the same element.
And even if I do, this gets even more nonsensical. Unless a processor writes code for every
individual constraint, there is no way for it to know what the constraint is doing. It can't know
whether resolving a content reference would be valid; it can only know that it might be
invalid. And as a result, I can't even reuse a
<keyword>, because somewhere
in my document, some constraint is defined.
- Be using differently constrained document types.
- While pulling from an unconstrained context into a constrained context.
- More specifically, I'd need to be pulling in the constrained element.
- And in this specific instance, the pulled element would have to violate the constraint.
- And for this not to enrage the average author, every other situation should allow the content reference, because it is valid, and dangit it should just work.
That scenario is so unlikely – and the frustration of not resolving an otherwise valid conref so much more likely – that the syntax and processing we've built to handle it is worse than useless.
I keep coming back to the fact that a processor cannot know from the token what is
constrained. Instead it must scan the token for
-c, to know that something
is constrained. This feels like a hack. If all we can know is "constraints are in use", why not just
use a common token to say that? Any processor can get just as much information, and do (or not)
exactly what it does today. For the token, I'd suggest something clear like
OK, fine. It's possible today for a processor to discover that my concept and my task use the
same constraint on
<li>, in which case, anything is available to conref. But
even allowing for that, our rules for constructing the token are still silly. That is,
(topic task strictTaskbody-c) is no more meaningful than
(strictTaskbody-c). So why does the spec have so many rules about constructing the