[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Complexity of bookmap content model
Luckily it seems we are agreeing much more than disagreeing and converging quickly! > -----Original Message----- > From: Christian Kravogel [mailto:dita@seicodyne.ch] > Sent: Thursday, June 15, 2006 11:19 AM > To: Esrig, Bruce (Bruce); Robert D Anderson; dita@lists.oasis-open.org; > '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" <robander@us.ibm.com> > To: "Esrig, Bruce (Bruce)" <esrig@lucent.com> > Cc: <dita@lists.oasis-open.org>; "'JoAnn Hackos'" > <joann.hackos@comtech-serv.com>; "Paul Prescod" <paul.prescod@xmetal.com> > 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)" <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 > >> > >> > >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]