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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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


Subject: Re: [Fwd: Re: DOCBOOK: Introduction & conclusion]


Nicolas Mailhot wrote:

| > | Well, I ended up making it a preface also. That's the most
| > | satisfying compromise I found.
| > | But it's really weird, adding a preface like that at the end
| > | of a document :(
| > 
| > What sort of a book is it, may I ask? I can't think of any books
| > I've encountered recently that had a "conclusion" chunk at the
| > end.
| 
| It's an academic report on a six-months internship. So
| you're expected to provide something called a conclusion at
| the end of your paper. Of course, no one will really read it
| (least of all this part), but it wouldn't be taken well if
| this elemnt was omitted.

and 

| Anyway I can easily think of technical books with
| conclusions ; take any translated work, the translator often
| adds a conclusion or afterwords where he puts his own stuff
| (remarks specific to his country, points on which he
| disagrees with the author...). He can not put them anywhere
| else because he is not supposed to alter the original in any
| way. But you can not translate a whole book without having
| something to add at the end.

Good.  Two examples.  First, the history.  We were modelling
a fairly broad selection of software documentation books, we
took care to handle cultural variation in sequence (of TOCs,
for example), and our formatting tools were primitive.  We 
now have ceased to require any particular order in the contents
of books, and we have more sophisticated formatting tools,
along with a very sophisticated developer helping us to use
them.

So it seemed to make sense to provide an element for Prefaces,
both to ensure that they came in the proper place in the book,
and to make it easy to avoid autonumbering them.  Had we thought
about Conclusions of the sort required for Mr Mailhot's report
(and I'm imagining that he might have numbered chapters but that
the Conclusion isn't numbered), we might have allowed for a 
generic unnumbered chapter element, or put an attribute on
Chapter to allow the user to indicate that it shouldn't be
numbered.  But we didn't, and in fact probably we would have
worried about allowing Prefaces where Conclusions should be,
and would have been unable to come up with a name for the
element.

So now, what to do?  The easy way out is, as Mr Mailhot found,
just to use Preface for Conclusion.  Another approach (which
fits the translation example) would be to make the main body
of the report a Part and follow that with a bare Chapter
that is titled "Conclusion", taking care that the Part formatting
is what you want. 

I'd be reluctant to rename Preface so as to avoid confusion 
when Preface is used for Conclusion, and happily (or not, we
shall see) we will soon be experimenting with XML Schema.
So I suggest that we recognize a new desideratum and deal
with it in Schema, where both Preface and Conclusion can
be subtypes of BookPartThatIsntAChapterAndComesAtTheBeginningOrEnd,
or give up the distinction between Preface and Chapter after
reflecting on what it's buying us today.

regards, Terry



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


Powered by eList eXpress LLC