Luckily it seems we are agreeing much more than disagreeing and converging quickly!
> -----Original Message-----
> From: Christian Kravogel [mailto:]
> Sent: Thursday, June 15, 2006 11:19 AM
> To: Esrig, Bruce (Bruce); Robert D Anderson; ;
> 'JoAnn Hackos'; Paul Prescod
> Subject: Re: [dita] Complexity of bookmap content model
>
> We are going to use the new DITA 1.1 bookmap for two customers (Kone and
> Novartis), and we indeed need a high flexibility of the base bookmap
> contentmodel when we are going to specialize it.
>
> After checking the latest proposal from Robert and comparing it with the
> needs for those two projects, I can definitely support Roberts proposal.
> It
> works fine to us.
>
> Having booklists in frontmatter meets our requirements perfectly, but I
> can
> imagine cases where some users might prefere to have booklists in the
> backmatter as well. E.g. someone requires toc, figurelist and tablelist
> before the chapters but glossarylist and indexlist after the chapters. And
> if, for any reason, this user can not leave the control for that order to
> the stylesheet.
>
> If nothing speaks against booklists in front and backmatter, I would
> suggest
> to have it in both.
>
> Best regards
>
> Chris
>
> Christian Kravogel
> SeicoDyne GmbH
> Eichenstrasse 36
> CH-6015 Reussbühl
> +41 41 534 66 97
> www.seicodyne.com
>
>
> ----- Original Message -----
> From: "Robert D Anderson" <>
> To: "Esrig, Bruce (Bruce)" <>
> Cc: <>; "'JoAnn Hackos'"
> <>; "Paul Prescod" <>
> Sent: Thursday, June 15, 2006 6:27 PM
> 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)" <> 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:]
> >> Sent: Thursday, June 15, 2006 10:53 AM
> >> To: Paul Prescod; Robert D Anderson
> >> Cc:
> >> 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
> >>
> >> joannhackos Skype
> >> www.comtech-serv.com
> >>
> >> -----Original Message-----
> >> From: Paul Prescod [mailto:]
> >> Sent: Thursday, June 15, 2006 8:49 AM
> >> To: Robert D Anderson
> >> Cc:
> >> 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
> >>
> >>
> >>
> >
