@domains for base Topic and Map Types

[Eliot Kimber <ekimber@contrext.com>]

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