RE: [dita] indexterm ambiguity

["JoAnn Hackos" <joann.hackos@comtech-serv.com>]

I agree with Paul's interpretation. That is the expectation that
indexers have in creating a secondary or tertiary index item. The page
number is attached to the lowest level.
JoAnn

JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joann.hackos@comtech-serv.com
joannhackos Skype
www.comtech-serv.com

-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Friday, July 28, 2006 12: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
>