Now with this understanding, suppose we have two maps as follows:
Map1.ditamap:
=============
Map2.ditamap:
=============
Now for Map1.ditamap, the keyspace shall be as follows:
Key | Target
==================
A | 1.dita
M2 | b.dita
M22 | b22.dita
B | c.dita
M33 | c33.dita
M4 | d.dita
M44 | d44.dita
D | map2.ditamap#tr05
M55 | e55.dita
- Keys C & E are ignored due to conref & topicsetref resolution.
- Key M3 is not there as due to conref resolution key B; the already existing @keys value gets used.
- Key M5 is not there as due to topicsetref resolution key D; the already existing @keys value gets used.
Please correct me if I am getting it wrong somewhere.
Regards,
Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com
Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com]
Sent: Thursday, September 02, 2010 4:39 PM
To: Tarun Garg; dita
Subject: Re: [dita] DITA v1.2 Review | @keys in a conref
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"