Subject: Re: [jats-list] BITS: Is there a canonical way to group multiple appendices and a glossary under a single 'Appendix' heading?|
From: "Imsieke, Gerrit, le-tex" <gerrit.imsieke@xxxxxxxxx>
Date: Tue, 03 Sep 2013 23:22:08 +0200
I agree with Tommie, but would add a further question. I agree your valid alternative is clumsy, but not because of the book-part. Rather, it is the fact that this part has no 'body' element, but a 'back' element, that makes me uneasy.
I.e. you have book-back/book-part/back where I'd expect book/back/book-part/body.
The fact that the book-part appears inside book-back is in my view sufficient to indicate its status as back matter. The glossary and two appendixes it contains surely constitute the body of the book-part in the back matter, not its back matter, don't they?
Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^
On Tue, Sep 3, 2013 at 12:04 AM, Tommie Usdin <btusdin@xxxxxxxxxxxxxxxx> wrote:Your "Valid alternative" is encoding the structure you describe. If, and this is a big IF, you are comfortable with the structure of the book, why would you not be comfortable with encoding the nesting as it appears in the book? You say that there is an Appendix which contains a Glossary and several titled structures at the same level as the glossary (which in BITS are tagged as <app>s) and after that Appendix there is an Index.
I think <book-part> in this use is serving exactly the function it was designed for: it is a structure in the book that can have any designation appropriate: chapter, volume, part, appendix, lesson, tutorial, and anything else an author or editor can dream up. Why shouldn't there be generic structures in the backs of books as well as in their bodies?
On Sep 2, 2013, at 6:32 PM, "Imsieke, Gerrit, le-tex" <gerrit.imsieke@xxxxxxxxx> wrote:
There's a book whose backmatter consists of a glossary, two appendices and and index. In the printed version, the glossary and the appendices are contained in a book-part-like structure with the heading 'Appendix'. The index heading is intended to be on the same level as this 'Appendix' heading. The individual appendices below the 'Appendix' heading have their own distinct headings (let's call them 'Author Biographies' and 'Handouts').
What is the canonical BITS way to encode this structure? I'll present a valid yet clumsy and an invalid variant.
<book-back> <book-part dtd-version="0.2"> <book-part-meta> <title-group> <title>Appendix</title> </title-group> </book-part-meta> <back> <glossary> <title>Glossary</title> </glossary> <app> <title>Handouts</title> </app> <app> <title>Author Bios</title> </app> </back> </book-part> <index> <title-group> <title>Index</title> </title-group> </index> </book-back>
I don't like that there's a book-part that could, in principle, host all kind of stuff that doesn't belong into a book's backmatter (front, body).
Or the use of a book-part in a book-back could lead you to think that the content now go into the book-part's body because you're already in the backmatter. Until you find out that an appendix or glossary can't be in the body.
Because I was kind of loath to use a book-part for the collective 'Appendix', I thought of using app-group, like this:
<book-back> <app-group> <title>Appendix</title> <glossary> <title>Glossary</title> </glossary> <app> <title>Author Bios</title> </app> </app-group> <index> <title-group> <title>Index</title> </title-group> </index> </book-back>
This looks more lightweight and appropriate in my view, except that glossary isnbt allowed in an app-group (only app elements are allowed there).
In principle, one could extract the glossary from the Appendix, leaving the two appendices proper under the Appendix heading, in an app-group. But if the glossary was moved before the appendices, there would be no 'Appendix' heading before the glossary which probably isn't acceptable for the author and/or the publisher. If the glossary were moved past the appendices, the order in the electronic pulication (EPUB derived from BITS) would deviate from what's been printed, and this also seems unacceptable to some of the parties involved.
So is there a third way to encode this in a natural way, or do you consider the book-part way (first alternative) as a natural way already? Or do you also think (as I do) that there should be a generic container to group backmatter components? It could be app-group, but maybe with a book-part-meta instead of a mere title element.
What do you think?
====================================================================== B. Tommie Usdin mailto:btusdin@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Phone: 301/315-9631 Suite 207 Direct Line: 301/315-9634 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in XML and SGML ======================================================================
-- Gerrit Imsieke GeschC$ftsfC<hrer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930
GeschC$ftsfC<hrer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt, Dr. Reinhard VC6ckler
|<- Previous||Index||Next ->|
|Re: [jats-list] BITS: Is there a ca, Wendell Piez||Thread||Re: [jats-list] BITS: Is there a ca, Nikos Markantonatos|
|Re: [jats-list] BITS: Is there a ca, Debbie Lapeyre||Date||Re: [jats-list] BITS: Is there a ca, Wendell Piez|