[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Complexity of bookmap content model
I hope I'm not coming into this too late... Catching up on messages I should have read ages ago. Our clients have the notices and things like that as part of the front matter. I see they're available only in backmatter. I'd like to see frontmatter include: notices?, specialnotices*, amendments?, ... (note there's a comma missing after notices?) If someone else has already brought this up, please disregard this email. Best Regards, Gershon --- Gershon L Joseph Member, OASIS DITA and DocBook Technical Committees Director of Technology and Single Sourcing Tech-Tav Documentation Ltd. -----Original Message----- From: Robert D Anderson [mailto:robander@us.ibm.com] Sent: Thursday, June 15, 2006 5:16 PM To: Paul Prescod Cc: dita@lists.oasis-open.org Subject: RE: [dita] Complexity of bookmap content model As nobody else seems to be responding, I'll go ahead and say that I support the changes that Paul suggested. I think it would make the bookmap more usable. Paul, I notice you questioned what to do with appendix elements (and presumably other back-matter elements) inside the part tag. With the new <backmatter> tag to hold these, did you expect to move back matter out of the part element? If so, I think the new structures you're suggesting would look more-or-less like this: <!ELEMENT bookmap (title, bookmeta?, frontmatter?, chapter*, part*, backmatter?, colophon?, reltable* )> <!ELEMENT frontmatter (booklists | draftintro | abstract | dedication | preface | topicref)*> <!ELEMENT backmatter (appendix*, notices? specialnotices*, amendments?, topicref* )> <!ELEMENT part (topicmeta?, chapter*)> 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/14/2006 03:11:24 PM: > I think that being able to put specialized "special chapters" > where-ever you want is a pretty big benefit, so I'm glad you pointed > out that advantage of a model with a more explicit structure. > > I'll throw out another benefit. In editors with a "collapse element" > construct, it would be great to be able to collapse the whole front > matter or back matter at once. > > -----Original Message----- > > From: Robert D Anderson [mailto:robander@us.ibm.com] > > Sent: Wednesday, June 14, 2006 12:53 PM > > To: Paul Prescod > > Cc: dita@lists.oasis-open.org > > Subject: RE: [dita] Complexity of bookmap content model > > > > Hi Paul, > > > > I will not argue against any of the proposals, except for one thing > > on > a > > technical basis. The map model does not allow reltables to appear > except > > as > > children of the map, so they cannot go in a grouping element at the > end. > > > > The topicref element at the end was created based on user feedback > that > > asked for a place to define sections we might not have thought of. > > So, > it > > is not just intended for relationships - it is also intended for > generic > > other sections, which would require updated processing in order to > appear > > in the right spot. Maybe you would want to change the > > <relationships> element at the end of bookmap to something like this > > (probably with a better name than otherbooksections)? > > <!ELEMENT bookmap (title, > > bookmeta?, > > frontmatter?, > > chapter*, > > part*, > > backmatter?, > > colophon?, > > otherbooksections?, > > reltable* )> > > > > Alternatively, with elements grouped into front and back matter, it > > probably makes more sense to have a topicref* inside each of those > > sections. This would allow special sections where they belong. > > Without > the > > front and back groupings, we had to pick only one location to > > include topicref*. > > > > 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/14/2006 > > 02:13:52 > PM: > > > > > Let me ask this again in a few ways. > > > > > > 1. Do current bookmap users see this content model as complex? > > > > > > 2. If not, how do you manage the complexity in your head? How do > you > > > remember what elements can go in what places? > > > > > > 3. Is there anyone out there who would argue against simplifying > the > > > model on a technical or usability basis? > > > > > > 4. Is there anyone who would argue against simplifying it on a > > > procedural basis ("too late. Will slow us down?") > > > > > > 5. What do people think about the particular simplification > proposal at > > > the bottom? Putting aside issues of title, the main ideas are > > > > > > * group front-matter and backmatter into their own > > > (topichead-like) elements. > > > > > > * to group the portion of the tree designed for creating > relationships > > > but not generating the table of contents (to help make the TOC > > > predictable) > > > > > > ===== > > > > > > Note the sort of document that the current model can generate: > > > > > > <bookmap> > > > > > > <title></title> > > > <part><appendix></appendix><appendix></appendix></part> > > > <part><chapter></chapter><chapter></chapter></part> > > > <colophon/> > > > <topicref></topicref> > > > <topicref></topicref> > > > <topichead></topichead></bookmap> > > > > > > * Chapters after appendices. > > > * Topicrefs after colophon. > > > * Topicheads after the colophon > > > > > > What should a TOC generator do with a topicref after the > > > appendices > and > > > colophon are done? > > > > > > Are the appendices within parts before chapters meant to be > > > gathered > for > > > the end of the book or published in-place in the middle of the > document? > > > > > > > -----Original Message----- > > > > From: Paul Prescod [mailto:paul.prescod@xmetal.com] > > > > Sent: Monday, June 12, 2006 2:29 PM > > > > To: dita@lists.oasis-open.org > > > > Subject: [dita] Complexity of bookmap content model > > > > > > > > Is anyone else concerned about the complexity of this content > model? > > > > > > > > <!ELEMENT bookmap (((%title;) | (%booktitle;))?, > > > > (%bookmeta;)?, > > > > ( (%booklists;) | > > > > (%draftintro;) | > > > > (%abstract;) | > > > > (%dedication;) | > > > > (%preface;))*, > > > > (%chapter;)*, ( ( (%appendix;)*, > > > > (%notices;)?, (%specialnotices;)*, (%amendments;)? ) | (%part;)* ), > > > > (%colophon;)?, > > > > (%topicref; | %reltable;)*)> > > > > > > > > I don't mind its size as much as its complexity. > > > > > > > > Even with validating editors like XMetaL, content models with > > > > many alternatives can be confusing. "I put an appendix in and > > > > now I > can't > > > put > > > > a part in before it. Why not?" > > > > > > > > Also: why do we want to allow multiple abstracts, dedications, > > > prefaces, > > > > etc. > > > > > > > > I could imagine something more like: > > > > > > > > <!ELEMENT bookmap (title, > > > > bookmeta?, > > > > frontmatter?, > > > > chapter*, > > > > part*, > > > > backmatter?, > > > > colophon?, > > > > relationships? ) > > > > > > > > I would expect the elements frontmatter, backmatter and > relationships > > > to > > > > be topicheads. > > > > > > > > Paul Prescod > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]