RE: [dita] Nested Sections - counterexample

From
France Baril <>
Date
2005-11-22T21:25:58+00:00
ID
Thread
RE: [dita] Nested Sections - counterexample
Hi 
Bruce.

 

If I understand your email correctly, you are 
questioning the fact that the current DITA model could be used in this specific 
case.

 

My uneducated answer would be a specialization 
similar to this (uneducated because I might be missing part of the 
context):

 

<lucenttask 
otherprops="lang(1)">

<shortdesc>Short description of the full 
procedure</shortdesc>

<lucenttaskbody>

<steps>

   <step>

       <cmd> what to do in Lang 1

       
<stepresult>what you have accomplished  <!-- The label is not 
necessary in the XML -->

       <related-step 
href="conreference to the full procedure in Lang 2#correspondingcmd"> 
<!-- output may or not include text of related cmd in lang 
2 -->

  </step>

<step> 

       <cmd> what to do in Lang 1 for next step

       
<stepresult>what you have accomplished  <!-- The label is not 
necessary in the XML -->

       <related-step 
href="conreference to the full procedure in Lang 2#correspondingcmd"> 
<!-- output may or not include text of related cmd in lang 
2 -->

  </step>

</steps>

<taskbody>

<related-links>

    <link href="cross-reference to 
the full procedure in Lang 2"> <!-- Layout may include shortdesc of 
referenced procedure -->

</related-links>

</task>

Is this a specialization, yes. Is this an issue? If you are going 
to base a whole project on the fact that you can reference another task in 
parallel, why not take the time to specialize and have a model that matches your 
specific needs? Creating a specialization is not a long task to perform, being 
able to change your mind on the presentation based on semantics might however 
save you a lot of time. 

 

What if you 
decide to hide this info to some people? What if you want to display the 
text in gray or with a different background-color so that readers see 
it as extra information, not core info? What if you want to generate reports on 
what references to what? What if you don't want to see the preceding label 
anymore? What if you want to inforce your model so that authors 
always write the stepresults before the related-steps? What if 
related-steps are treated differently then other regular xrefs so that they 
actually extract the text from the referenced cmd?

 

This sounds to me like a big enough requirement to 
justify sending a new request to the development team. A few hours of 
development on the core model might save you long hours of 
hacking.