RE: [dita] indexterm ambiguity

["Esrig, Bruce (Bruce)" <esrig@lucent.com>]

There's a major ambiguity in our specifications regarding indexterms that seems to be caused by the nesting.

We are interpreting a nested set of indexterm entries both as a definition of one entry and as a definition of multiple entries.

There are two decisions to transmit to the production system: (a) we seem to have decided (naturally) that the nested set of indexterm element instances generates a nested set of index entries and (b) we need to know at each level whether the indexterm entries trigger the generation of page numbers in the output.

Bruce Esrig

-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com]
Sent: Wednesday, July 26, 2006 3:36 PM
To: dita@lists.oasis-open.org
Subject: [dita] ignoring the index-range-end's parent indexterm


In the writeup for index-range-start, we say:

 * If there is an indexterm with a range start marker but
   does not have a corresponding indexterm that ends the range,
   it should just generate a single page number reference in
   a book as if there was no range start marker.
 * On the other hand, an indexterm that terminates a range
   but has no corresponding indexterm that starts the range
   should be dropped entirely from output.

I have a concern with the second bullet.

What should happen in the case of:

<indexterm>chese<index-range-start/></indexterm>
. . .
<indexterm>cheese
  <indexterm>sheeps milk cheeses
    <indexterm>pecorino<index-range-start/></indexterm>
  </indexterm>
</indexterm>
. . .
<indexterm>cheese<index-range-end/>
  <indexterm>sheeps milk cheeses
    <indexterm>pecorino<index-range-end/></indexterm>
  </indexterm>
</indexterm>

[note "chese" instead of "cheese" in the initial indexterm]

According to the current wording, because the cheese's
index-range-end is unmatched, we should drop its
indexterm entirely.  But that means we lose the
perfectly fine pointwise indexterm to "sheeps milk cheeses"
as well as the properly match index-range-end for "pecorino".
I don't think we want to do that.

In fact, even loosing the perfectly fine pointwise indexterm
reference to "cheese" doesn't seem right.  (The problem here
isn't the end term at all--it's the start term.)

So I am suggesting we change our solution to say that unpaired
index-range-start/end's are ignored, but their containing
indexterm is never ignored.

paul