dita — archive

[Eliot Kimber]

The recent discussion around ditabase and the various task configurations suggests that we need more public discussion of why DITA imposes what may at first appear to be draconian constraints on conref. I think it's important to understand that there are several different use cases in which constraints are or are not important, but that, overall, the constraints are necessary in order for DITA content to be both interoperable and interchangeable. In the case of processing, for the most part, conref constraints are not relevant, because most, if not all processors, will be able to process any valid DITA elements, in any combination, constrained or not. That means, for example, that a constrained topic referencing content from an unconstrained topic wouldn't normally cause problems for processors. I suspect this is the way most DITA users think about the implications of conref constraints. [Note: This is not the same as allowing specialized elements to conref unspecialized content--that's a different issue and allowing that *would* break processors, because specializations may establish specific contracts for what they can contain and how they need to be processed. The textbook example is