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 <p> 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 person.

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.

For this to actually help prevent a bad thing but not disable valid reuse, I'd need to:
  1. Be using differently constrained document types.
  2. While pulling from an unconstrained context into a constrained context.
  3. More specifically, I'd need to be pulling in the constrained element.
  4. And in this specific instance, the pulled element would have to violate the constraint.
  5. 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 (hey-i-know-this-is-silly-but-i-am-feeling-constrained).

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 former?