RE: [dita] Complexity of bookmap content model

["Grosso, Paul" <pgrosso@ptc.com>]

Although I could imagine one mixing appendices
and glossaries and indexes (Knuth's TeXBook put
the index in Appendix I and then still has an
Appendix J, but I personally think that's too
cute by half), I would not argue that we need
to allow that in DITA.

But "done by the transform" doesn't address my
concern.  Yes, when transforming legacy data into
DITA, one can do some restructuring, but my point 
with the CALS DTD wasn't just about legacy.  Rather,
I mentioned that as an example to show that it's
not uncommon for users to think of appendices being 
part of the backmatter.

A lot of the arguments for how we are structuring 
the rest of the front and back matter in this thread
had to do with how customers do things, and I'm saying
customers want to put appendices in back matter.

So in response to:

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

I'm saying I think we should keep appendix in the
back matter as currently (when I left on vacation)
designed.

paul

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Monday, 2006 June 26 17:05
> To: Grosso, Paul
> Cc: dita@lists.oasis-open.org
> Subject: RE: [dita] Complexity of bookmap content model
> 
> Hi Paul - do you think it would be acceptable for that to be 
> controlled in
> the transform? That is - I expect we will already have an IBM 
> processing
> override that will put back matter sections into the order 
> that meets our
> style. It could easily pull the appendix sections into the 
> back matter,
> placing them before or after the other sections. In fact we 
> will have to do
> that when converting to our SGML document type, because that requires
> appendix tags to appear inside the back matter.
> 
> I think the only thing this rules out is the ability to 
> create Appendix A,
> followed by the glossary or index, followed by appendix B, 
> but I do not
> think that would be too common.
> 
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit
> (507) 253-8787, T/L 553-8787
> 
> "Grosso, Paul" <pgrosso@ptc.com> wrote on 06/26/2006 10:51:40 AM:
> 
> > Sorry, but I was offline for the last 10 days.
> >
> > I am in general in favor of the direction of
> > this simplification of the bookmap content model.
> >
> > However, I think appendix should be allowed in backmatter.
> > I've certainly seen applications where appendices
> > are considered part of the backmatter.  For example,
> > the standard CALS (US DOD) DTDs have:
> >
> > <!ELEMENT rear ( appendix | glossary | index | errpt | foldsect)+ >
> >
> > paul
> >
> > > -----Original Message-----
> > > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > > Sent: Friday, 2006 June 16 09: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.
> > >
>