RE: Consolidated index

["Susan Ahrenhold" <sahrenhold -at- winspc -dot- com>]

The main reason to produce a consolidated index is to overcome the
artificial constraints placed on a "bunch" (technical term) of information
caused by dividing the bunch into volumes. If it is tricky to tell where
specific information is contained, then a consolidated index might well be
worth it. After all, who wants to consult six different individual indexes?
This also helps if the information bunch each approaches a topic from its
own point of view. This means that the user information about why to use a
particular tool is in one volume, the programming constructs behind the tool
are in another volume, and the instructions for linking the information to
another program are in a third. This allows users to read all the different
approaches, and possibly, develop a comprehensive overview of the needed
information.

That said, these indexes can be a pain to develop and maintain.
Library reference materials, traditionally the home of information organized
in this fashion, use techniques such as Volume/Page number control, which is
very similar to the scheme you proposed.
Such documentation requires that somebody be responsible for making sure
that the terms used in the index are consistent across the sub-indexes, or
to make sure that there is extensive cross-referencing. If no one does, then
you might as well just omit the shared index (for example, if one book used
appliance for what another book calls a device, in effect you are not
sharing information across documents unless you use see or see-also
references.

I have worked on documentation sets where a concept is discussed across
multiple volumes, and the resulting index was useful. But it's not a walk in
the part, and an appropriate volume identification scheme is only one of the
worms that comes out of the can.