[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]