OASIS Open Mailing List Archives  ·  All Lists  ·  dita  ·  2013-04

dita — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Fwd: [dita] TractorX Example


Joann, Thanks, that’s a great example. And I think 13004 will cover it, regardless of the resolution of the global scope namespace question. The issue isn’t whether you can nest scopes to arbitrary depths - that’ll be there either way. The question is how, in such maps, cross-scope addressing will work. It sounds like this example is more about being able to have a hierarchy of scoped key definitions, and not necessarily about linking across those scopes. To be concrete, you could have maps that looked like this: <map> <title>All Product Lines</title> <mapref href= /> <mapref href= /> <! -- etc. --> </map> <map keyscope="model3900A" > <title>Model 3900A</title> <keydef keys="modelConrefs" href= /> <topicref href= /> <mapref href= /> </map> <map keyscope="model3900L" > <title>Model 3900L</title> <keydef keys="modelConrefs" href= /> <topicref href= /> <mapref href= /> </map> <map> <title>Electrical Systems</title> <topicgroup keyscope="elec-40V" > <keydef keys="electricalConrefs" href= > <topicref href= > </topicgroup> <topicgroup keyscope="elec-24V" > <keydef keys="electricalConrefs" href= > <topicref href= > </topicgroup> <! -- And so forth. --> </map> Any of the topics could have conkeyrefs to modelConrefs/modelName, modelConrefs/modelDescription, etc. Because of the presence of @keyscope on the model-level map, those key references will resolve to the ‘local’ binding for the modelConrefs key, without interfering with the binding for that key in the other model maps. Also, the electricalSystem.dita file could have conkeyrefs to electricalConrefs/whatever that would resolve differently for each instance, due to the presence of @keyscope on the topicgroups. And because those ‘elec-*’ scopes are children of the ‘model’ scopes, they can also reference modelConrefs/*, and get the appropriate bindings for the current model. The issue at hand is what happens if you had a conref to “elec-24V.electricalConrefs.” Would you link to the ‘local’ copy of electricalConrefs, or the first one in the overall map hierarchy? Chris From: JoAnn Hackos [mailto:[email protected]] Sent: Tuesday, April 09, 2013 9:19 PM To: DITA TC; Eliot Kimber; [email protected] Subject: Fwd: [dita] TractorX Example 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 < [email protected] > Date: April 9, 2013, 7:01:41 PM CDT To: JoAnn Hackos < [email protected] > 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

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]