I have two, which may be very silly
questions/solutions but let me know.
1) Why couldn’t you create a
specialization for these clients which allows them to nest sections just for
those topics where they are creating questions?
2) It seems to me that the most the people
are nesting these sections is one level deeper than the actual section content
unit. What if we introduced a subsection element that is allowed for one level under
the section content unit?
I think that if this is critical enough we
can put mechanisms in place to prevent users from nesting sections to any level
they want.
Jen
Jen
Linton
Comtech
Services, Inc.
Senior
Consultant and Web Manager
710 Kipling St. Suite 400
Denver, CO 80215
P:
303-232-7586
F:
303-232-0659
From: Paul Prescod
[mailto:]
Sent: Thursday, November 03, 2005
3:25 PM
To: Michael Priestley
Cc:
Subject: RE: [dita] Nested
Sections
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.
>
>
>
