[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Complexity of bookmap content model
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 > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]