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: Nikos Markantonatos <nikos@xxxxxxxxxx>
Date: Wed, 04 Sep 2013 12:59:11 +0300
Folks,

> This looks more lightweight and appropriate in my view, except that
> glossary isnbt allowed in an app-group (only app elements are allowed
> there).

I follow the discussion on this subject and there are valid arguments on both sides. However, it seems that the very purpose of introducing the <book-back> element is to allow for the "lightweight" solution which Gerrit initially attempted. Alas, this solution could not work for Gerrit because <glossary> cannot appear inside <app-group>, which is a requirement for his book instance.

So that's where I would focus to solve this problem. The placement of <glossary> could be made more flexible. It is already allowed inside <app> and a bunch of other places, I see no reason why this is not useful inside <app-group> as well. This would allow for the "lightweight" solution to work out fine.

This is not to say that the "clumsy" solution is out of the question, some people may actually opt for that solution instead. But it is clear from previous discussions that the "lightweight" solution has its share of fans too.

Regards,
Nikos


On 09/03/2013 01:32 AM, Imsieke, Gerrit, le-tex 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

Current Thread