OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]