Action: Comment C029: Compatibility of Domains with Map.mod

[Eliot Kimber <ekimber@reallysi.com>]

I've done an analysis of all the topic domains (that is domains that are not
expressly map domains).

None of the domains specialize elements found in topic.mod nor in map.mod
(naturally, since these are topic domains and therefore could never
specialize map/topicref).

I made a little spreadsheet if anyone wants to see my work.)

This means they must only specialize elements defined in commonElements.mod,
which means that they must be compatible with map.mod, which means that it
should be completely valid and safe to integrate any of the standard-defined
topic domains with map.mod.

Assuming my analysis is correct, I think that leaves the following question
for the TC:

Should we update the map.dtd in technicalContent to include the following
domains?

- abbreviate
- highlight
- programming
- software
- ui

I don't think hazard statement is applicable in maps as there is no context
within which a hazard statement (that is, a note) can usefully occur within
a map. That is, while one could build a structure that would allow a note to
occur within navtitle or linktext, that's definitely not an intended thing
to do in general (I think we can agree that notes are not appropriate
content for titles and link text).

This change would make the TC-provided technical content map document type
consistent with the technical content topic document type.

I can't think of any reason not to make this change unless there's some tool
out there that would be seriously inconvenienced by the possibility of more
elements within <navtitle> or <linktext>, which there shouldn't be since any
DITA user could do this themselves if they so desired.

Another alternative would be to move the current map.dtd into the base
directory and create a more complete map.dtd under the technical content
directory.

That is, there's no reason we can't provide multiple document type shells
now that we have a clear functional organization of the vocabulary modules.

[In fact I think it would be convenient to provide a topic.dtd that includes
no domains or only the domains within the base directory, but I'm not going
to suggest it for 1.2.]

I will respond to Jeremy to the effect that we are considering the
suggestion.

Cheers,

Eliot
-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com