RE: [dita] Complexity of bookmap content model

[<mark@mekon.com>]

I have always considered chapters and appendices to follow on from
eachother and therefore keeping <appendix> outside of backmatter seems a
more logical approach.

I cannot remember seeing a document that has some other type of
"section" between chapters and appendices (i.e. the other elements
defined in backmatter).

It is also quite common for glossaries to be in an Appendix.  
Glossaries are currently supported under the booklists element. In this
case I'm not sure it needs to be handled specifically within the DTD but
is a real world example that should be considered.

Regards

Mark Poston
Mekon Limited
www.mekon.com
Tel: +44 (0)20 8722 8461
Skype: mark_mekon.com (work)

XML Content Management? XML Publishing? Visit www.x-pubs.com Europe's
largest XML Publishing conference, 20-21st June 2006

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com]
> Sent: 16 June 2006 15:10
> To: Paul Prescod
> Cc: dita@lists.oasis-open.org
> Subject: RE: [dita] Complexity of bookmap content model
> 
> During this ongoing discussion, Paul Prescod and I each got an
off-list
> note that requested keeping appendices out of the backmatter, because
they
> are not backmatter. Are there any other opinions on this? So, that
would
> remove <appendix> from the back matter, and change the bookmap model
to:
> <!ELEMENT bookmap (title, bookmeta?,
>        frontmatter?, chapter*, part*, appendix*, backmatter?,
>        reltable* )>
> 
> One side advantage I see to this is that it keeps all of your
appendices
> together; you won't accidentally stick your index between Appendix C
and
> Appendix D. Of course if anybody wants the other back matter before
the
> appendices, they may see it as a disadvantage. Are there any other
> comments
> on this? If it's as easy as the others, we can probably go ahead with
it,
> but if it is controversial I think we should keep it in the back
matter as
> currently designed.
> 
> Thanks-
> 
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit
> (507) 253-8787, T/L 553-8787
> 
> "Paul Prescod" <paul.prescod@xmetal.com> wrote on 06/15/2006 01:19:42
PM:
> 
> > I think that I read somewhere that the current model is intended to
> > support BOTH people who want to specify the order in the map AND
people
> > who want to override those decisions in the stylesheet. I think
that's
> > wise.
> >
> > I personally have no problem with colophon and booklists being
optional
> > at both the front and the back. I'd rather restrict preface to the
front
> > and appendix to the back.
> >
> > It doesn't matter to me whether appendices are within backmatter or
just
> > before the backmatter in bookmap.
> >
> > > -----Original Message-----
> > > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > > Sent: Thursday, June 15, 2006 9:28 AM
> > > To: Esrig, Bruce (Bruce)
> > > Cc: dita@lists.oasis-open.org; 'JoAnn Hackos'; Paul Prescod
> > > Subject: RE: [dita] Complexity of bookmap content model
> > >
> > > To take a little step forward - the revised model, without getting
in
> > to
> > > shared front or back matter items, would be this:
> > > <!ELEMENT bookmap (title?, bookmeta?,
> > >       frontmatter?, chapter*, part*, backmatter?,
> > >       reltable* )>
> > >
> > > <!ELEMENT frontmatter (booklists | draftintro |
> > >        abstract | dedication | preface | topicref)*>
> > >
> > > <!ELEMENT backmatter (appendix | notices |
> > >        specialnotices | amendments | colophon |
> > >        topicref)*>
> > >
> > > <!ELEMENT part (topicmeta?, (chapter | topicref)*)>
> > >
> > > I'll just note here that the title is optional, just because it is
in
> > the
> > > current implementation. Earlier emails implied it would be
required.
> > >
> > > About placing items in both the front and the back - I'm not
voicing a
> > > strong opinion on that either way (though some pretty clearly make
> > sense
> > > in
> > > only one spot, like preface in the front). The original idea was
to
> > have
> > > some sort of style setting that controlled where the items went.
For
> > > example, the index is in <booklists>, which is only in front
matter;
> > > default processing would usually stick it at the end. A style
setting
> > > could
> > > move it before the appendix, after it, or whatever. You know, that
old
> > XML
> > > principal - I just have to say I want an index, and my build
process
> > > controls where to put it.
> > >
> > > I'll note that allowing <booklists> in both spots was not possible
> > before
> > > the <backmatter> and <frontmatter> containers, which may be why it
> > never
> > > came up. There's no technical limitation on it once those are
added.
> > >
> > > Robert D Anderson
> > > IBM Authoring Tools Development
> > > Chief Architect, DITA Open Toolkit
> > > (507) 253-8787, T/L 553-8787
> > >
> > > "Esrig, Bruce (Bruce)" <esrig@lucent.com> wrote on 06/15/2006
09:57:48
> > AM:
> > >
> > > > > What about the extra topicref for specialization?
> > > >
> > > > To second that, Lucent allows an overview topic in a part before
> > > thechapters.
> > > >
> > > > Regarding front matter and back matter, a flexible content model
is
> > > better.
> > > >
> > > > Which items do we know are either front matter or back matter
but
> > > > not both? For example, would the order of booklists in the book
be
> > > > completely up to the processing, or is it under author control?
> > > >
> > > > Bruce
> > > >
> > > > -----Original Message-----
> > > > From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
> > > > Sent: Thursday, June 15, 2006 10:53 AM
> > > > To: Paul Prescod; Robert D Anderson
> > > > Cc: dita@lists.oasis-open.org
> > > > Subject: RE: [dita] Complexity of bookmap content model
> > > >
> > > >
> > > > I would support having colophon in both front and backmatter as
> > options.
> > > > Standards among publishers are variable around this. I would not
> > enforce
> > > > order in the backmatter either.
> > > > JTH
> > > >
> > > > JoAnn T. Hackos, PhD
> > > > President
> > > > Comtech Services, Inc.
> > > > 710 Kipling Street, Suite 400
> > > > Denver, CO 80215
> > > > 303-232-7586
> > > > joann.hackos@comtech-serv.com
> > > > joannhackos Skype
> > > > www.comtech-serv.com
> > > >
> > > > -----Original Message-----
> > > > From: Paul Prescod [mailto:paul.prescod@xmetal.com]
> > > > Sent: Thursday, June 15, 2006 8:49 AM
> > > > To: Robert D Anderson
> > > > Cc: dita@lists.oasis-open.org
> > > > Subject: RE: [dita] Complexity of bookmap content model
> > > >
> > > > Now that we're getting down to detail...
> > > >
> > > > > <!ELEMENT bookmap (title, bookmeta?,
> > > > >       frontmatter?, chapter*, part*, backmatter?,
> > > > >       colophon?, reltable* )>
> > > >
> > > > The current model has two ways of representing the title. I
don't
> > > > totally understand that design but hope to within a few days.
> > > >
> > > > Can we move colophon into the backmatter?
> > > >
> > > > > <!ELEMENT frontmatter (booklists | draftintro |
> > > > >        abstract | dedication | preface | topicref)*>
> > > >
> > > > Looks good.
> > > >
> > > > > <!ELEMENT backmatter (appendix*, notices?
> > > > >        specialnotices*, amendments?, topicref* )>
> > > >
> > > > Is there a reason to enforce order and cardinality on the
backmatter
> > but
> > > > not the frontmatter?
> > > >
> > > > > <!ELEMENT part (topicmeta?, chapter*)>
> > > >
> > > > What about the extra topicref for specialization?
> > > >
> > > >  Paul Prescod
> > > >
> > > >
> > > >
> >
>