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
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).
>