atom feed38 messages in org.oasis-open.lists.ditaRE: [dita] Complexity of bookmap cont...
FromSent OnAttachments
Paul PrescodJun 12, 2006 2:28 pm 
Robert D AndersonJun 12, 2006 3:11 pm 
Erik HennumJun 12, 2006 4:07 pm.gif, .gif, .gif, 7 more
Paul PrescodJun 12, 2006 6:09 pm 
Erik HennumJun 13, 2006 8:10 am 
Paul PrescodJun 14, 2006 12:13 pm 
Robert D AndersonJun 14, 2006 12:53 pm 
Paul PrescodJun 14, 2006 1:10 pm 
Robert D AndersonJun 15, 2006 7:16 am 
JoAnn HackosJun 15, 2006 7:34 am 
Paul PrescodJun 15, 2006 7:48 am 
JoAnn HackosJun 15, 2006 7:52 am 
Esrig, Bruce (Bruce)Jun 15, 2006 7:57 am 
Robert D AndersonJun 15, 2006 9:27 am 
Esrig, Bruce (Bruce)Jun 15, 2006 9:39 am 
Robert D AndersonJun 15, 2006 9:43 am 
JoAnn HackosJun 15, 2006 10:08 am 
Paul PrescodJun 15, 2006 11:19 am 
Paul PrescodJun 15, 2006 11:20 am 
JoAnn HackosJun 15, 2006 11:22 am 
Robert D AndersonJun 16, 2006 7:09 am 
ma...@mekon.comJun 16, 2006 8:28 am 
JoAnn HackosJun 16, 2006 10:51 am 
Robert D AndersonJun 16, 2006 6:13 pm 
Paul PrescodJun 16, 2006 6:24 pm 
Paul PrescodJun 19, 2006 9:56 am 
Robert D AndersonJun 19, 2006 10:12 am 
Robert D AndersonJun 19, 2006 11:26 am 
Esrig, Bruce (Bruce)Jun 19, 2006 12:11 pm 
Robert D AndersonJun 19, 2006 12:20 pm 
Gershon L JosephJun 26, 2006 7:48 am 
Grosso, PaulJun 26, 2006 8:51 am 
Robert D AndersonJun 26, 2006 3:04 pm 
Grosso, PaulJun 26, 2006 3:20 pm 
Paul PrescodJun 26, 2006 3:38 pm 
Robert D AndersonJun 26, 2006 5:03 pm 
Paul PrescodJun 26, 2006 5:59 pm 
Grosso, PaulJun 27, 2006 7:06 am 
Subject:RE: [dita] Complexity of bookmap content model
From:Robert D Anderson (roba@us.ibm.com)
Date:Jun 26, 2006 3:04:37 pm
List:org.oasis-open.lists.dita

Hi Paul - do you think it would be acceptable for that to be controlled in the transform? That is - I expect we will already have an IBM processing override that will put back matter sections into the order that meets our style. It could easily pull the appendix sections into the back matter, placing them before or after the other sections. In fact we will have to do that when converting to our SGML document type, because that requires appendix tags to appear inside the back matter.

I think the only thing this rules out is the ability to create Appendix A, followed by the glossary or index, followed by appendix B, but I do not think that would be too common.

"Grosso, Paul" <pgro@ptc.com> wrote on 06/26/2006 10:51:40 AM:

Sorry, but I was offline for the last 10 days.

I am in general in favor of the direction of this simplification of the bookmap content model.

However, I think appendix should be allowed in backmatter. I've certainly seen applications where appendices are considered part of the backmatter. For example, the standard CALS (US DOD) DTDs have:

<!ELEMENT rear ( appendix | glossary | index | errpt | foldsect)+ >

-----Original Message----- From: Robert D Anderson [mailto:roba@us.ibm.com] Sent: Friday, 2006 June 16 09:10 To: Paul Prescod Cc: di@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.