OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

ignoring the index-range-end's parent indexterm

  • 1.  ignoring the index-range-end's parent indexterm

    Posted 07-26-2006 19:36
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    dita message

    [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]