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