Forum Stats

  • 3,838,975 Users
  • 2,262,432 Discussions
  • 7,900,825 Comments

Discussions

Merging indexitems

When I have an index that looks like this:

<indexitem text="Files">
<indexitem text="batch">
<indexentry target="batchfiles" text="Batch Files"/>
</indexitem>
<indexitem text="database">
<indexentry target="dbfiles" text="Database Files"/>
</indexitem>
</indexitem>

the locators (i.e. targets) for the two secondary indexitems are also included as hits in the primary indexitem. We would prefer that not to happen. Is there any way that I can do this, or can this behavior be changed in a later version?

Jeff

Comments


  • When the user clicks on a primary keyword, we
    create the list of topics by adding the topics
    associated directly with the primary keyword
    first, then we append the topics associated
    with the subkeywords.

    This seems like a reasonable approach to us.
    In particular, it is possible in Oracle Help
    to have a primary keyword that does not have
    any topics associated directly with it. In
    other words, a primary keyword can be used
    simply as a container of subkeywords. When
    clicking on a primary keyword with no topics
    directly associated, I think showing the topics
    associated with subkeywords is beneficial.

    If there is a case where the above approach
    isn't reasonable, or you simply would prefer
    we don't merge, we could add a way to configure
    it in a future release. What do you think?



  • 187538
    187538 Member Posts: 24
    In general, that is a reasonable approach. We simply have a huge helpset and are working to improve our index. One of the types of index that we envision where this approach is particularly bad is something like this:

    commands
    ANTYPE
    NLGEOM
    ...

    where topics with general information on issuing commands could be linked under the primary indexterm and topics with information specific to a particular command would be grouped under the secondary indexterm. That is a somewhat contrived example, but in general, due to the sheer size of information we're handling, this approach leads to several cases of "bloated" primary indexterms.

    I would be more than happy if this were a feature that I could configure, either using the Java API or as an attribute in the indexfile itself. (e.g. <index version="1.1" mergesecondaries="no">). If you really feel like having fun, you could allow index authors to specify this on a per-indexitem basis.

    Jeff
This discussion has been closed.