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
Thanks for the clarifications - that's
what I get for commenting without complete information :-(I agree there's a mismatch between the
customer requirements and the current model, and I agree changes need to
be made to accomodate them. However, I'm going to keep beating at the issue
a bit longer - basically I'd rather keep the topic model, and occasionally
end up with some topics that are like sections, than break the topic model,
and end up with lots of sections that are like topics (where I fear this
would end - not in your case in particular, but in the community of use
in general).Here's another potential treatment of
the model, without breaking the section nesting rule (albeit breaking tons
of others, which just happen to matter to me less):learningobject title body questions
question
title
body
question
title
body conclusion related-linksTo make this work we'd need a number of changes to the
existing content model for topic:- (for <questions>) allow wrapper elements after
the body, equivalent to <linkpool> or <linklist> but for topics
rather than links- (for the new placement of links) allow nested topics
and related-links to occur in any order - (for conclusion) allow topics without a title (assuming
the heading will be generated) (would need to add some fallback logic for
linking transforms)We'd need to add new processing etc. to support all this
(having a conclusion topic without a title would in particular cause some
pain for our linking transforms), but I'm hoping this would meet your customer's
needs while avoiding the topic chunking issue. Thanks for providing the concrete example - it's a lot
easier for me to work through, and I hope I'm not appearing too recalcitrant
on the topic issue. We both want DITA to meet your requirements, my wriggling
is an attempt to do so while preserving what are, for other users, critical
architectural requirements.Michael Priestley
IBM DITA Architect
SWG Classification Schema PDT Lead
mpriestl@ca.ibm.com
1. The questions are not topics
because they are not (in this customer's context) designed to be meaningful
_on their own_. They could refer to the content above them or the question
above or below them. 2. The customer wants the wrapper
for the reasons I described below. The wrapper simplifies authoring. The
wrapper simplifies formatting. The wrapper guarantees that the questions
are always together (there might be other kinds of sub-topics). 3. Your model requires the questions
to be the last thing in the topic, except for another subtopic. But the
customer might want "back matter" for a topic that also makes
no sense as a standalone topic. e.g., they think of the related-links element
as following the questions (both for authoring and publishing). We're contorting the way they
model and think about their system and I don't really understand how they
or we benefit.
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Wednesday, November 02, 2005 7:54 PM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Nested Sections
If you modeled each question as its own topic, you would not need a container
topic called "Questions".
Example:
<learningobject id="x">
<title>...</title>
<body>...</body>
<question>
<title>..</title>
<body>..</body>
</question
<question>
<title>..</title>
<body>..</body>
</question
<question>
<title>..</title>
<body>..</body>
</question
</learningobject>
Underneath the covers, there'd be two specialization modules, integrated
into a doctype that specifies "learningobjects contain questions".
But to the user, this would be very similar to the structure you described
below, just without the container element.
Michael Priestley
IBM DITA Architect
SWG Classification Schema PDT Lead
mpriestl@ca.ibm.com
In a previous discussion, Michael asked why nest sections when you can
nest topics. My opinion is as follows.
If topic-based authoring means anythng then it means that you don't
arbitrarily shred everything with a title into a topic. Topics are
things that have meaning ON THEIR OWN. A section that is inherently
embedded in its context should not become a topic to fulfill an
arbitrary requirement of a framework.
Our customer is in the e-learning domain. He has "questions"
that are
directly related to the surrounding content. The questions are richly
structured like sections. The set of questions needs a wrapper element
to supply a title and organize the authoring experience.
Reusable Learning Object
Information
Information
Questions
Question title
Para
Para
List
Para
Question
Para
List
Table
Para
Question
Para
Table
Para
So in this case I'm not looking for infinitely nested sections. I just
need two levels hard-coded into the specialized topic type. I don't
think that this design is controversial, innovative or unique.
If I turn "Question" into a topic type then I also need to turn
"Questions" into a topic type and its only purpose is to wrap
up other
topics. Plus I cannot default the title. Plus there are content
management and policy implications, because the customer wants all
topics to be content managed objects and all content managed objects to
be topics (in the sense of being inherently designed for reuse). (which
seems quite reasonable to me)
My other use case is wrapping up multiple elements to supply a single
conditional attribute on them.
Para
Section audience="expert"
Para
Para
Section product=""
Para
Para
Para
Para
I would also use this mechanism to conref more than one element at a
time. (I personally prefer this to a range-start/range-end model).
>