The collection of tokens in @domains serves to define the document

While I consider this one to be a decent theoretical justification for the various @domains tokens, it has one deeply fatal flaw, and is also useless in a practical sense.

The following quote appears in the DITA 1.2 specification topic about assembling custom document types (emphasis added):

The DITA document type is defined entirely by the set of modules declared on the @domains attribute of the document's root element and by the values of the @class attributes of all the elements in the document. If the @domains attribute declares both structural and domain vocabulary modules, then the @domains attribute by itself serves to define the DITA document type. The information on the @domains and @class attributes is sufficient to implement all DITA-defined processing and constraint checking on documents (for example, determining if a referenced element in a content reference has a set of modules compatible with the modules used by the referencing element's document).

Thus, DITA does not require that conforming DITA documents have an associated DTD, XSD, or other formal document type definition as long as all required attributes are explicit in document instances.


This idea is theoretically quite interesting, but also virtually useless in a practical sense. The idea is that if I know all of the tokens in @domains, and know what grammar module each of those tokens represents, then I know all of the rules for editing my topic – even if I don't have a DTD, Schema, or RelaxNG rule set. Indeed, very interesting. And if there were other solid reasons for having these tokens, I'd be all in favor of pointing this out.

However – I can see no real world scenario where 1) I'll be editing a topic without the rules present, and 2) my editor will be smart enough to read those tokens, figure out what they mean (reminder: still no registry of domain tokens!), and use that knowledge to guide my authoring.

If I'm merely processing the document (not editing), then @class alone is all I need to usefully process the document (except for the two cases I think should be handled in other ways).

Also – the emphasized line from DITA 1.2 (which was removed from DITA 1.3) has a fatal flaw.

<ominousMusic>The Fatal Flaw</ominousMusic>

@domains doesn't have a token to define topic nesting.

I can have a specification-compliant document type where <topic> nests <concept>, and another where it does not, with exactly the same set of tokens in @domains. Edge case? Maybe, but unlike every other edge case I've described here, I've actually seen this in the real world.

Given that I can have two different documents with different rules, which use exactly the same set of @domains tokens, it cannot be correct to say that @domains by itself defines a DITA document type.

Note: In the pre- DITA 1.0 days, we thought about this. I remember discussing potential syntax that would say "topic can nest topic". But look at the composite document type in DITA 1.0, where <concept> could nest all of <topic>, <concept>, <task>, and <reference>. Now imagine a syntax that could convey this without being so over-the-top complex as to be meaningless. I saw some proposed samples. I might even have suggested some. They all violated the "over-the-top meaningless" guideline.