Hmm
... let's try in that spirit ... (I can see this affecting the way that we
choose to generalize task.)
According to this scenario, if we're offering an
alternate command, we'd have to agree in the information architecture on what
label to autogenerate for it. It wouldn't be user-settable.
If we grant that, another deviation is that it looks as
though the link inside a step is a non-DITA thought. In fact, putting a jump to
a related topic in every step might not be the right thing to
do.
Note also the implicit query here: why do we
distinguish <info> from <itemgroup>? At first glance, the
similarities are striking.
Best wishes,
Bruce
===========
lu-task is a specialization of
topic/topic
lu-taskbody is a specialization of
topic/body
Anything I want before the steps is a specialization of
one of our div elements, or of section.
There
could be a section that contains the steps (not shown, and perhaps not part of
the solution).
The
steps might need to be generalized a little bit.
If
<info> can contain everything that <itemgroup> can contain, then
it's not a big deal.
gen-step is a specialization of li
cmd
and stepresult are as currently defined
alternate-cmd is a new element that extends gen-step compared with step
and is a specialization of itemgroup
If it
autogenerates a label, it would have to be something generic such as
"Alternate".
related-step is a specialization of link. It's pretty radical,
right? Even going up to topic, I'm having trouble finding a context that would
allow a link.
<lu-task
otherprops="lang(1)">
<shortdesc>Short description of the full
procedure</shortdesc>
<lu-taskbody>
<gen-steps>
<gen-step>
<cmd> what to do in Lang 1
<stepresult>what you have accomplished <!-- A label such
as "Result" will be autogenerated
-->
<alternate-cmd>lang 2 command to achieve the same result <!-- may be
suppressed in some outputs -->
<related-step
href="reference to the full procedure in Lang 2#correspondingcmd"> <!--
may be suppressed in some outputs -->
</gen-step>
<gen-step>
<cmd> what to do in Lang 1 for next step
<stepresult>what you have accomplished <!-- A label such
as "Result" will be autogenerated
-->
<alternate-cmd>lang 2 command to achieve the same result <!-- may be
suppressed in some outputs -->
<related-step
href="reference to the full procedure in Lang 2#correspondingcmd"> <!--
may be suppressed in some outputs
-->
</gen-step>
</gen-steps>
</lu-taskbody>
<related-links>
<link href="cross-reference to
the full procedure in Lang 2"> <!-- Layout may include shortdesc of
referenced procedure -->
</related-links>
</lu-task>
-----Original Message-----
From: France Baril
[mailto:]
Sent: Tuesday, November 22, 2005
4:26 PM
To: Esrig, Bruce (Bruce);
Subject: 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.
