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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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

Subject: Re: [docbook] RFE 714764 - 'typed' indexes

Tobias Reif <tobiasreif@pinkjuice.com> writes:

> Michael Smith wrote:
> >      - Indexterm also has specialized attributes; for example:
> >
> >        * Zone, which makes it possible to place your Indexterms
> >          anywhere you want in document (e.g., you can collect them all
> >          together if you want, instead of needing to physically place
> >          them in the part of the document you want to index)
> Does that mean that I could create (not generate) two different indexes 
> (sets of index terms) for the same document, as two separate XML documents?

I'm not sure what you mean by "two separate XML documents" or how that
relates to the what the DocBook DTD allows or doesn't allow.

If you mean putting the sets of index terms into separate physical files
and then conditionally including one or the other -- via XInclude or
some Makefile entity/file switching or whatever -- yeah, I guess you
could. Of course nothing in the DTD would prevent you from doing that. 

Or do you mean putting multiple sets of indexterms into the same source
document, with a plan of conditionally including/excluding certain sets
from processing?

If so, on the authoring side, I guess you could either put some kind of
wrapper element around your Indexterm sets, with a different value for
the role or some other attribute on the wrapper element for each set, or
you could just use different values for the role attribute on each
Indexterm, to indicate which set it belongs to -- to classify or 'type'
each Indexterm -- basically the same thing the proposed 'type' attribute
is intended to be used for.

All that said, of course you'd need to have some support on the
processing side for generating multiple indexes and for doing
conditional processing of your Indexterm sets -- the 'profiling'
capability in the DocBook xslt stylesheets or something similar. Without
that. Otherwise, the processing app is just going to put contents of all
the sets into the default index.


P.S. As far as the wrapper idea goes, since there is no standard element
in DocBook for wrapping sets of Indexterms, you'd need to choose one.
It would be best to an element whose contents are suppressed in output,
but I can't think of any like that except the *info elements, and those
are only once per component.

No matter where you put them, your Indexterms themselves wouldn't be
rendered. But if you wrap them in some element whose contents are
normally rendered -- Para or whatever -- you may end up with some extra
empty lines in your output (margin-top/margin-bottom space) in place of
the expected content.

PGP signature

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