We have been following the discussion and have a real-life example to offer.
This organization is a long time DITA user that we need to move to keys away from conditional processing.
The complexity is stunning.
JoAnn Sent from my iPhone JoAnn Hackos Comtech Begin forwarded message:
From: Dawn Stevens <
>
Date: April 9, 2013, 7:01:41 PM CDT
To: JoAnn Hackos <
>
Subject: FW: [dita] TractorX Example So perhaps a Real life example might help? Within one document, we have discussions on how to connect power cables to three cabinet types -- the -40V, 24V, and 220V cabinets. We want to write one topic that uses keys to change the power supply and a few isolated steps within the procedure. But all three topics will appear in the document, so each doc when included in the map needs a unique key scope. Now we want to put that document into a library of many documents for different product lines. In addition to the unique elements of the three cabinets, these topics also appear in the entire library multiple times based on the product line -- the 3900, 3900A, 3900L -- and each of these products has multiple versions. So in this library the topics need the power supply keys at the individual topic level, but the product and version keys at the book level. Within the library we might have 3 voltage topics that appear in each of three versions of three different product books. If I understand correctly, to specify keys without hierarchy would mean specifying 27 keys each time the topic was used, instead of being able to specify one key def at the topic level and two key defs at the book level for each of the nine books. Now I know we question why this organization structures their library this way, but it is a real-life application of why we need this to work. Dawn
