[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] RE: Bookmap implementation
I'm a little bit worried about the precedent of creating containers, so that we can continue copying/pasting the other elements unchanged. This is really going to be an issue with every map specialization. You will often want to provide context when you reference a topic - indicate that when you point to a topic at this location in this map, it plays a specific role. Specialization is the normal DITA mechanism for doing this, so it seems normal to me to point directly to a topic with a specialized topicref. We've got some pretty heavily specialized maps in use that do the same thing, and have not had any problems with them. I would think that changing this will cause people to shy away from similar useful specializations in the future. So, I'd rather not toss out the existing model. I think that the issue of adding a new parent topic to the chapter will come up seldom enough that many people will not want to deal with the extra container. Keeping the individual chapter elements does also provide a usability gain for large bookmaps, because - when scrolling through that map in an editor that gives you an XML view - it is easier to identify where you are (something I have run in to working with the language reference). The fact that there are at least a couple of bookmap implementations available, and that users of those have not complained, seems to indicate that this is not a critical problem. I think rather than changing the markup to force users into grouping elements, I would tend to prefer the solution Deborah suggested on Sunday (if I understood it correctly) -- that is, <chapter href="topicA"> indicates that topicA starts a chapter, while <chapter> indicates that the child topicrefs each start a chapter. Or, allow the alternative of a grouping element -- (chapters | chapter)*, where chapters functions as a group and has no href. The same would probably be done for (parts | part) and (appendices | appendix). Users could decide which they find easier to work with. Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 "W. Eliot Kimber" <ekimber@innodata-isogen.com> wrote on 02/13/2007 06:18:30 AM: > Yas Etessam wrote: > > France might not have been the only person sleeping, removing the > > chapter element and defining chapter-level information as descendants of > > chapter group does seem like a good suggestion, albeit a late suggestion. > > I was sleeping too. I agree with France's analysis and would prefer a > "chapters" (or "bookbody") wrapper--that is how I structure all of my > book-ish schemas. > > I have the same complaint about DocBook. > > Given that there is no (official) legacy for bookmaps, I think we have a > little more room to make this change if we can get consensus quickly. > > Cheers, > > E. > -- > W. Eliot Kimber > Professional Services > Innodata Isogen > 8500 N. Mopac, Suite 402 > Austin, TX 78759 > (214) 954-5198 > > ekimber@innodata-isogen.com > www.innodata-isogen.com >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]