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


Hoping to get through bookmap items quickly tomorrow, I think we have the
following options for the appendix element. I do not remember who first
brought up the "appendices are not back matter" view point but I am hoping
that person will speak up. I personally do not have a strong opinion on
which of these options to choose, although I am inclined to agree with Paul
Prescod's note below.

1. Leave appendices as approved last week. An output process can place them
before the back matter or within it. Bookmap contains
 ... appendix*, backmatter?

2. Allow the appendices in both spots, but force them to the start of the
back matter so that they still stay together. An output process will have
to determine how to merge them if coded in both places. I believe Paul
Prescod has pre-emptively voted against this. In option #2, Bookmap
contains
.... appendix*, backmatter?

backmatter contains
(appendix*, (everything else)*)

3. Move the appendix into back matter, but keep all appendices together. An
output process will have to be able to move the appendices in front of any
"Back matter" section. The bookmap element no longer contains appendix.
Back matter contains
(appendix*, (everything else)*)

4. Move the appendix into back matter, and allow it to freely mix with
other sections. An output process will have to be able to move the
appendices as in option 3. The bookmap element no longer contains appendix.
Back matter contains
(appendix | everything else)*

5. The go-all-out option, where appendix is allowed in bookmap as currently
approved, as well as anywhere in back matter. Output processing needs to
figure out how to merge or arrange them. Again, I think we have Paul
Prescod's vote against this one.

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/26/2006 05:38:48 PM:

>
>
> > -----Original Message-----
> > From: Grosso, Paul [mailto:pgrosso@ptc.com]
> > Sent: Monday, June 26, 2006 3:18 PM
> > To: dita@lists.oasis-open.org
> > Subject: RE: [dita] Complexity of bookmap content model
> >
> > ...
> >
> > A lot of the arguments for how we are structuring the rest of
> > the front and back matter in this thread had to do with how
> > customers do things, and I'm saying customers want to put
> > appendices in back matter.
>
> But I think that Robert is saying that _during output_ you can put the
> appendices in the back matter. It is only really necessary to put them
> in the back content model if we want the user to have precise control
> over where appendices occur relative to other back matter items (like
> booklists, notices, colophon and amendments).
>
> If the author needs control then we should put it in the content model.
> If it is just a matter of putting the appendices and other stuff into a
> special back matter section for output purposes, then it should be done
> in a stylesheet.
>
> We SHOULD put it in both places if different people really need
> different structures for output or processing reasons. We SHOULD NOT put
> it in two places if we are really just debating the meaning of the
> phrase "back matter". Some people seem to classify appendices as back
> matter and others do not. If their output and other processes end up
> looking the same then the definitional issue is not key.
>
>  Paul Prescod



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]