OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Nested Sections



Hi Eliot,

It's much easier for me to work with concrete examples. Is Paul's sufficient, or is there another case you could provide?

Our difference of opinion may just come down to what I said in my response to Paul:
>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

I think the discussion is important because it's exposing requirements on DITA that we should address, but I am hoping to preserve the basic topic orientation of the architecture, if necessary by increasing the flexibility with which we allow nesting of topics.

Michael Priestley
IBM DITA Architect
SWG Classification Schema PDT Lead
mpriestl@ca.ibm.com



"Eliot Kimber" <ekimber@innodata-isogen.com>

11/03/2005 10:09 AM

To
<dita@lists.oasis-open.org>
cc
Subject
Re: [dita] Nested Sections





Paul Prescod wrote:

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

I think this is the crux of the discussion: some things *must* be topics
and some things *must not* be topics--that is the distinction between
topic and section.

In particular, if the information is titled but cannot stand alone then
it *cannot be* a topic and therefore must be a section. If it can stand
alone and it is a candidate for re-use (in the sense that it is not
explicit disallowed as a re-use target) then it must be a topic.

Whether or not a section has sub-hierarchies is irrelevant: either it
stands alone if it doesn't. Just having sub-hierarchy doesn't affect its
standaloneness.

Therefore I submit that, from the standpoint of topic-based writing it
doesn't matter whether sections nest or not, the problem is the same: is
what I'm writing obligated to be or not be a topic? This is the
fundamental challenge of topic-oriented writing.

It is also the case that allowing nested sections allows abuse by
authors, but that cannot be our concern: we are not responsible for
enforcing authoring policy, only for enabling satisfaction of
requirements. If nested section is a loaded gun then we have an
obligation to provide gun safety training but we can't simply outlaw
guns because some people might shoot themselves.

That is, given that we understand the distinction between topics and
not-topics and the implications of making that distinction correctly we
have an obligation to educate the community on how to make that
distinction clearly.

I have heard from others, who shall be nameless, that they have abused
other elements specifically in order to get the effect of nested
sections. This is additional strong evidence that there is a legitimate
and compelling requirement for such a structure.

It's also important to keep in mind that the very beauty of DITA is that
specializers can impose any constraints they want (consistent with the
base content models), so if people want a world where nested sections
are not allowed they can easily build that world.

Cheers,

E.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]