Reviewing the previous 1.3 review draft, the current language says: "Each structural, element, and attribute domain defines its module ancestry as a parenthesized sequence of space-separated module names from root module to provided module." Thus, for a topic type of "reference" the @domains value would be "(topic reference)", not "(topic)". That is, the type itself is included in the ancestry specification. By that logic, for topics of type "topic" and maps of type "map" the @domains value should be "(topic)" and "(map)". The next paragraph defines the @domain syntax for *element domains*. However, there is no syntax definition for *structural* domains. So, we could read that as implicitly allowing "(topic)" (because it's not explicitly disallowed) and leave the current language as it is. Or we could add a new syntax definition for structural domains that allows a single type token. Based on Robert's argument and the text as written, I think that the 1.3 map and topic shells (base map, base topic, tech content map, tech content topic) should specify "(map)" or "(topic)" as their structural domain contribution. Because the specification says that structural types should specify their structural ancestry I think we are obligated to provide a domains contribution for all TC-provided structural types. Note also that the spec says that for the purposes of conref compatibility the @domains value is used to compare *domains* not structural types: "The @domains attribute allows processors to determine whether two elements use compatible domains." Thus a comparison of maps to topics for the purpose of allowing conref from maps to topics would only consider domains, with the common elements effectively being a domain (or set of domains) that all topics and maps inherently share. The OT currently allows conrefs from maps to topics (I have a client with exactly that case that I've been working with just in the last few days), so we can presume it was always intended that it be allowed. That suggests that we should probably make that case explicitly allowed for elements that are common between maps and topics. Note also that it must be the case that conref constraints related to specialization (target same or more specialized than reference) can only be defined in terms of @class values as long as @domains is not required for structural types, so any rules related to allowing maps to conref from topics would need to be defined in terms of @class values. That is, for the purpose of checking conref constraints, @domains is still only used to compare domains used, not structural types. Structural type comparison is done using @class. Finally, on the subject of actually using @domains to dynamically construct working grammars for documents: With RNG this is now actually possible since RNG domains are self-integrating: One could literally use the @domains value to construct an inclusion list of domain modules given a mapping from domain module names to module files (which should always be a one-to-one mapping since you should never have two different versions of the same domain module for a given DITA version). This was not really practical with DTD or XSD, but I think it is practical with RNG. If somebody did implement this it would make it easier to interchange DITA files without having to also interchange the grammars since useful RNG shells could be reconstituted on demand by the receiver. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC
http://contrext.com