RE: [dita] indexterm ambiguity

["Grosso, Paul" <pgrosso@ptc.com>]

You are correct that this is a key issue.

I've come to the conclusion that the only workable 
interpretation is that a nested set of indexterms 
defines only one entry, the multi-level one.

That is:

<indexterm>cheese
  <indexterm>sheeps milk cheeses
    <indexterm>pecorino</indexterm>
  </indexterm>
</indexterm>

is equivalent to the DocBook markup:

<indexterm>
  <primary>cheese</primary>
  <secondary>sheeps milk cheeses</secondary>
  <tertiary>pecorino</tertiary>
</indexterm>

and, if this were the only indexterm in a document, 
would result in:

cheese
  sheeps milk cheeses
    pecorino                               5

If you want something like:

cheese                                     5
  sheeps milk cheeses                      5
    pecorino                               5

for your result, you have to have three top-level 
indexterms in your input:

<indexterm>cheese</indexterm>

<indexterm>cheese
  <indexterm>sheeps milk cheeses</indexterm>
</indexterm>

<indexterm>cheese
  <indexterm>sheeps milk cheeses
    <indexterm>pecorino</indexterm>
  </indexterm>
</indexterm>

This interpretation does answer some of my other
index related questions, though several remain.

And we do need to ensure the DITA spec is unambiguous
about all this.

paul

> -----Original Message-----
> From: Esrig, Bruce (Bruce) [mailto:esrig@lucent.com] 
> Sent: Wednesday, 2006 July 26 15:46
> To: Grosso, Paul; dita@lists.oasis-open.org
> Subject: RE: [dita] indexterm ambiguity
> 
> 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
>