MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Nested Sections - counterexample
Thanks to you,
Discussions always bring more dimensions to issues
that seem very simple at first. I had fun playing with your examples.
I hope you can let us know the results of your project once
its implemented.
<info> vs <itemgroup> --> They are similar
because task/info is a specialization of topic/itemgroup :-)
France
Yes,
thanks very much for the discussion, France.
>
an alternate command
It
would be great if we could conref the actual command template from somewhere,
but we don't have a fine-grained conref in our XML environment. We have the
ability to incorporate content by reference, but it incorporates the entire
target file. Also, we restrict its use to larger chunks such as chapters,
LU-LiPP sections (similar to DITA topicgroup), topics, LU-LiPP blocks
(equivalent to DITA sections), and s few smaller chunks such as figures and
graphics.
>
<info> vs <itemgroup>
I'm
hoping that Michael or Rob Anderson will take note of this. The content models
are so similar that it seems to me that one element could serve for both. Maybe
we can merge them in DITA 2.0.
>
leverage on meaning and really separate content from
presentation
This is a really interesting theme in your use of
DITA.
The part that scares me about this is that I've seen people use
markup for enforcement purposes. "This is what the markup allows, so this is
what you have to do."
I'm in
favor of specializations that provide guidance and structure. I love to
formalize things. And I can see that specialization can provide meaningful
elements that then can serve as guideposts for users, and triggers for special
treatment during various transformations (transformations for alternate outputs,
for translation to other notations, and to perform actual output
processing).
In the
base language, we should be as generic as we can afford to be, since there is
nowhere else to start when specializing. There is a danger of doing so much
specializing that the set of viable elements at a given point becomes
unmanageably large for the authors. So specializations should be used only when
there is a clear small set of choices that will be candidates in any given
situation.
The
modular nature of DITA encourages specialization since it permits use only of
those specializations that are appropriate to the application that the author is
working with. It also enables specialization to be done in a more distributed
manner, by information architects comparatively close to the authors that have
the need for specialized elements.
With
appropriate generalization, we can keep the need for specialized elements from
becoming overwhelming. So "alternate command" becomes a good auto-generated
title for additional information within a step (when the information needs to be
presented in a separately-labeled chunk such as a
paragraph).
This
also preserves Michael's cherished value: that DITA should be restrictive, and
not permit user-defined titles to appear in arbitrary places. Considering that
the topic has a user-defined title, and there is one more level of user-defined
title permitted within that, any further urge to have user-defined titles may
indeed indicate a chunking failure: somewhere, something needs to be elevated
and made into a separate topic.
I have
tried a couple of times to disprove this rule and in all honesty, I can't do it.
I hope that we don't put a complex mechanism in place to enforce the rule and
then find out it is incorrect. For cognitive reasons, I have hope that the rule
is correct. That is, topics should have a well-defined structure, and one level
of user-defined title within a topic is enough. Without that limitation, the
topic is too free-form, and the end user will see information that is not
sufficiently consistent.
I'll
keep looking for examples, but I am thinking that this rule will
survive.
Again,
thank you for your prominent defense of the point of view that specialization is
a good way to achieve controlled variation. I think it transfers the obligation
for creative generalization to information architects, which may be a good place
(at least for us!) for that obligation to reside.
Best
wishes,
Bruce