dita — archive

[Eliot Kimber]

For the purpose of constructing a key space, the system should resolve any non-key-based conrefs in the maps, determine the effective map tree, and then construct the key space. Key-based conrefs between maps and maps or topicrefs and topicrefs cannot be resolved until the key space has been constructed and therefore cannot affect the key space. Once the key space has been constructed then all remaining key-based conrefs can be resolved, which determines the final map tree, but cannot change the effective key space. Because any use of a key for conref must ultimately use an href to address the document that contains the conref target (in this case, map documents for the case of topicref-to-topicref conrefs), then every map document will be part of the map tree. The only question is *where* in the map tree the map's topicrefs occur for the purpose of determining the key space. That is, you could have a key-based conref of a key-defining topicref that occurs before the direct reference of the map containing that key definition. If a definition of the same key name occurs between the conref and the inclusion of the map containing the conref target topicref, then the intervening key definition will be the effective definition (because of the precedence rules of key definitions). Said simply, only directly-conreffed (that is addresed by hrefs) topicrefs and maps can be resolved during key space construction. Or even more simply, only directly-addressed maps contribute to the key-space-defining map tree (which subsumes direct conrefs of topicrefs since a direct conref of a topicref must first address the map document that contains the topicref, adding that map to the effective key space map tree). In practice this should not be an issue because there is no good use case that I can think of for conreffing topicrefs and this very limitation would further argue against using conrefs in maps, given that there are other facilities for combining map components into composite maps. Note that the DITA 1.x spec *cannot* mandate a processing sequence because of backward compatibility issues (see the non-normative interoperability appendix, which explains some of the issues around this fact). So whether conref resolution is performed before or after key space construction is up to processors, but since keyref is an entirely new feature one hopes that processors will implement it consistently. Cheers, Eliot On 9/2/10 3:50 AM, "Tarun Garg"