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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

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

Subject: RE: [docbook-apps] Re: Request For Clarification: Indexterm processing in auto-index generation.

Dave Pawson [mailto:davep@dpawson.co.uk] wrote:

> Cavicchio_Rob@emc.com wrote:
> > Dave Pawson [mailto:davep@dpawson.co.uk] wrote:
> > 
> >> My basic point is that the author should identify duplicates
> >> (perhaps from viewing the presented format) and do 
> something about it.
> > 
> > 
> > I disagree with this, because it forces the author to 
> presume a specific
> > output format when creating the source. 
> That provided by docbook XSLT?

I didn't understand your question. I don't want to code XML to work only
for HTML output, because I might generate both PDF and HTML output from
the same source.

> > I think the transforms should be smart enough to collapse identical
> > entries in HTML topics. However, if there is only one instance of a
> > particular index term in a topic, then I agree that it should go
> > directly to the anchor point rather than the top of the page.
> Which is becoming almost a programming language for indexing?

I don't see a problem with that, if it's the right thing to do. I've
seen some pretty creative XSL code.

> They can't be collapsed if they point to quite different
> points in the document? Or at least it wouldn't make
> sense to me to do that.

I think we'll need to agree to disagree on this point. I can see where
you're coming from if you typically have long, long sections that
translate to HTML topics. But most topic-based HTML output has
reasonably short topics, and these are manageable chunks to deal with as
index results. IMO, when you have a topic with two identical index
entries that is even 2 or 3 screens long, then essentially much of the
topic relates to that entry.

If your topics are typically much longer than that, I agree this
behavior wouldn't work. Perhaps the behavior could be controlled by a

Rob Cavicchio
Senior Technical Writer
EMC Captiva
EMC Corporation
10145 Pacific Heights Boulevard, 6th Floor
San Diego, CA 92121-4234

P: (858) 320-1208
F: (858) 320-1010
E: Cavicchio_Rob@emc.com

The opinions expressed in this message are my own and should in no way
be interpreted to reflect the opinions of EMC.

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