10.1.3 Understanding problems with processing conkeyrefs

DITA2Go processes conkeyrefs at the same time as keyrefs, after reading all the original maps and before processing any map conrefs. Adding maps by conref after that has the potential to change the keydefs. For example, if the top level map conrefs a topicref in an external map that contains keydefs, those keydefs would theoretically be higher priority than any referenced in lower-level maps. But the keyrefs in all the existing maps have already been resolved, so there is a contradiction. DITA2Go handles this problem by disregarding keydefs found in conref'd topicrefs.

If the keydefs are in the original set of maps, they will be used to resolve any conkeyrefs in those maps, and that will happen before any new maps are conref'd. For that case, conkeyref is identical to conref. But if a conref'd map element itself has a conkeyref, DITA2Go still uses the original keydefs to resolve it. If the new element has a key not present in the original set, but perhaps present in itself, that new keydef will not be used. So in that unusual case a conkeyref may or may not work, but a conref will work.

Previous Topic:  10.1.2 Pushing content into an element

Next Topic:  10.2 Referencing external code or text fragments

Parent Topic:  10.1 Pushing and pulling content by reference

Sibling Topics:

10.1.1 Referencing internal and external maps and topics

10.1.2 Pushing content into an element