Re: [jats-list] BITS: Is there a canonical way to group multiple appendices and a glossary under a single 'Appendix' heading?

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
On 03.09.2013 22:22, Wendell Piez wrote:
Gerrit,

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.

Yes, that's what made me uneasy, too. Just in case I didn't express my unease appropriately in first place.



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?

In <del>decent</del> other schema languages, you'd be able to specify that body has a different content model when it's the body of a book-part in a book-back. Not so much in DTD.


I think that book-part is too generic a container for backmatter constituents. We'd probably revert to Schematron in order to rule out front-matter and body in book-back/book-part because I don't see a use case for them.

I was hoping that app-group might provide this generic yet not too generic functionality of a basket for all kinds of backmatter parts, but it's too limited in scope.

If you look at front-matter-part's content model, you discover that someone has deliberately excluded front from the allowed children. I thought of an analogous back-matter-part that only has book-part-meta and an element that may contain everything that back may contain. Or short-circuit this in allowing book-part-meta within back.

Gerrit


Cheers, Wendell


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?

-- Tommie




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.

Valid alternative:

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

Gerrit


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

Current Thread