This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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. --Mike 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.
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |