Message-Id: <9302251437.AA11719@sc.zib-berlin.dbp.de>
Reply-To: Mailing list for the LaTeX3 project <LATEX-L@vm.urz.Uni-Heidelberg.de>
In-Reply-To:  <9302250954.AA27547@HP5.ITI.INFORMATIK.TH-DARMSTADT.DE>
              from"Nelson H. F. Beebe" at Feb 24, 93 09:33:07 am
Date:         Thu, 25 Feb 93 15:37:10 CET
From: Joachim Schrod <schrod@ITI.INFORMATIK.TH-DARMSTADT.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@vm.urz.Uni-Heidelberg.de>
To: Multiple Recipients of <LATEX-L@vm.urz.Uni-Heidelberg.de>
Subject:      Re: subdocuments
Status: R


Nelson wrote:
>
> The issue I raised at the Portland TUG meeting in July 1992 was the
> observation that current LaTeX styles require the author to make a
> decision about sectioning levels that is hard-coded into the document
> with \chapter, \section, ...  I believe this is highly undesirable;
> what we should be using is relative section naming; with suitably
> clevel macros and document styles, this need not imply that names
> other than \chapter et be used by authors.

It is of course desirable, but needs attention by the author. There
was recently a discussion con comp.text.sgml on this topic, I append
an article which features an opposite view.

--
Joachim

---------------- included article follows:

Newsgroups: comp.text.sgml
From: maler@abyss.zk3.dec.com (Eve Maler UEG Doc)
Subject: Re: Division nesting
Message-ID: <1993Feb16.175942.20229@decvax.dec.com>
Organization: Digital Equipment Corporation - Nashua, NH
Date: Tue, 16 Feb 1993 17:59:42 GMT

Hi, Wayne.  Nice to be talking with you about this again. :-)

Lots of folks express the desire to reuse division "subtrees," and this
seems to be the main reason that generic nested divisions get chosen.
As Wayne points out, writers must be aware of the possibility of reuse;
otherwise they will erect literary obstacles against the reuse (e.g.,
"This chapter discusses..." introductions can't be reused at lower levels).

I'm confused as to why there's such a strong desire for this, given the
constraints it puts on writers to write naturally (at least in regular
old book-like documents), given the alternatives, and given that such a
DTD for regular books allows for documents that nest to unacceptable numbers
of levels.  There are several *additional* obstacles to overcome with this
method.

In most book-style documents that have several levels of division nesting --
my group mostly does software documentation -- writers assume that each
lower-level division depends on the context that the upper-level
(containing) divisions provide.  That is, the reader is expected to have
the knowledge already provided at upper levels.  Yanking something out of
context and using it elsewhere at a different level (or for an audience
with a different knowledge base, or...) is rarely successful without careful
assumptions about context, audience, etc.  In practice, the information
design methodology you adopt along with a plain "book" document type is
too imprecise a tool to help you with the goal of reuse.

Various information design methodologies, such as Information Mapping(tm),
Weiss structured documentation, and UNIX man pages, change these default
assumptions by explicitly modularizing and flattening the information and
spelling out when relying on context is safe (e.g., across divisions in a
man page) and when it isn't (across manpages).

Rather than making the DTD seem to resolve the reuse issue magically by
nesting divisions recursively, I think it's much better to develop the
kind of modular document structure you want and make the DTD reflect it
explicitly.  This has several benefits.  Flat information has less need of
context and can be reused more safely.  "Module" elements can be placed
wherever you want in a document hierarchy with no worry about levels because
they come with their own internal structure.  You can design your modules
to "include" related information by reference (links) rather than by
value (actually including a subdivision), which is safer and perhaps less
wasteful of disk space, paper, etc in delivery.  And your applications can
make use of the semantics you've added to your documents.

My opinion--

	Eve Maler
	maler@zk3.dec.com