I think that we have an inherent philosophical difference.
I would be surprised if you could name a user of DITA who depends upon the fact
that sections cannot nest. You might be able to name users who do not want
sections to nest _at their site_ and _for their users_, but DITA
inherently allows them to enforce those rules and will do so even more after
Erik's widely lauded proposal is incorporated into DITA. I see the changes you
propose as much more destructive than the section nesting one. For example, the
invariant that all topics have a title is embedded in all DITA software and in
most people's thinking about DITA's data model. If we allow sections to nest, we
just have to set up some new stylesheets to handle the different section
levels.
I find the argument that we need to protect ignorant people
from themselves only compelling when it does not cause a burden for knowledgable
people. In this case it does.
From: Michael Priestley
[mailto:]
Sent: Thursday, November 03, 2005 1:24
PM
To: Paul Prescod
Cc:
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-links
To 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
"Paul Prescod"
<>
11/03/2005 11:43 AM
To
Michael
Priestley/Toronto/IBM@IBMCA
cc
<>
Subject
RE: [dita] Nested
Sections
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:]
Sent: Wednesday, November 02, 2005
7:54 PM
To: Paul Prescod
Cc:
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
"Paul Prescod"
<>
11/02/2005 07:48 PM
To
<>
cc
Subject
[dita] Nested
Sections
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).
> -----Original Message-----
> From: Eliot Kimber
[mailto:]
> Sent: Wednesday, November 02,
2005 12:00 PM
> To: Michael Priestley
> Cc: Paul Prescod;
; ; Jerry
> Silver;
> Subject: Re: [dita] Thoughts On
Sections
>
> Michael Priestley wrote:
> >
> >
What is it about nested sections in particular that makes them more
>
> suitable for your purposes than nested topics?
>
> The
distinction is that the sections do not meet the
> requirements for
topics, namely that they are not suitable
> for standalone use, that
they cannot stand by themselves.
>
> This is not just a semantic
distinction for information
> content but could have content management
implications. For
> example, a likely content management scenario is
that all
> topics are managed as separate storage objects. Using topics
> simply to get the effect of nested sections would interfere
>
with this as it would require either additional business
> rules based
on something like an outputclass attribute value
> or other
distinguishing metadata value or some other,
> non-DITA-defined, way of
distinguishing *real* topics (those
> that are inherently re-usable)
from "section" topics (those
> that are not inherently re-usable and
that should not be made
> available for re-use by default).
>
> Again, I agree with Paul that in a standard as general as
>
DITA it is simply inappropriate to impose this degree policy
>
constraint--it is imposing an editorial policy that is not
>
universally accepted.
>
> And I do not agree that nested sections
some how destroy the
> essential nature of DITA. It simply requires, as
DITA already
> does, that you think clearly about what are topics and
what
> are not and what your editorial policies for them are.
>
> And as there are ample mechanisms for imposing constraints
>
(either through specialization or through the new constraint
>
mechanism) anyone who feels strongly that sections should not
> nest
can impose that constraint.
>
> In any application standard there
is great temptation to
> impose policy decisions. In standards with
very specific uses
> that can be appropriate, but the more general a
standard is
> the less appropriate it is. This is something we
struggled
> with in HyTime.
> > My personal feeling is that at
the lowest level an
> architecture like DITA should impose almost no
constraints,
> serving primarily to establish the names of things with
only
> those context constraints needed to have a sensible base,
> with all other constraints being imposed at higher levels of
>
specialization. This helps ensure the widest applicability in
> the
future and avoids unnecessary constraints.
>
> Cheers,
>
> E.
>
>
>
