RE: [dita] indexterm ambiguity

["Chris Wong" <cwong@idiominc.com>]

I agree, and I regret that this was not clear in the proposal. Each top
level (i.e., not nested within a parent indexterm) indexterm element
should generate at most one index entry page reference.

Chris

-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Friday, July 28, 2006 2:55 PM
To: dita@lists.oasis-open.org
Subject: RE: [dita] indexterm ambiguity

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
>