Need to generalize when domains are specialized from structures
This is where the syntax for
@domains tokens really went off the rails,
in DITA 1.2 and 1.3. There is a theoretical value here, for complex specialization modules that rely
on unrelated modules.
However: although such modules exist, they are not common, unlikely to be generalized, and the token syntax is so complex that I doubt anybody will ever figure out how to make use of it.
As a highly improbable example, imagine I've created a domain with the specialized section
<goofyStuffToDo>. That section nests
<steps>, which is
pulled from the Task structural specialization. So far so good - complicated and a bit of an edge
case, but legal and useful.
Now imagine that for some reason this domain is made obsolete, and I want to turn
<goofyStuffToDo> back into
<section>. If I do that on its
<steps> element ends up invalid - because it's not allowed inside a
normal section. This means that if I ever generalize my domain, I also need to generalize any
task related elements inside.
Wait, what now?
Generalization is already an edge case; chances of needing it here => truly the bleeding edge.
Like, really way out on the edge.
If I ever decide to generalize this sort of document, I'm willing to bet I'll just be converting everything I find back to a basic topic, in which case the token is irrelevant. Remember - the token is only useful if I want to generalize this module (plus any dependent modules) to something other than topic.
This is so unlikely, I can't see any case where it is worth supporting. Even if I thought I was ever going to encounter this, the domain token syntax is so complicated that I doubt I could implement it. With syntax so complex that the implementation becomes near-impossible, what was the point of the syntax?