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] 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
> > chapter group does seem like a good suggestion, albeit a late
> 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]