[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