RE: [dita] treating index-see as index-see-also

["Esrig, Bruce \(Bruce\)" <esrig@lucent.com>]

Spinning out the example further ...

Wouldn't the resulting index be somewhat unusable? If a user looks under
Carp, they wouldn't see a reference to Goldfish, but some of the index
entries are under Goldfish.

In case this sort of clash occurs, to keep the index semantically
coherent, the reverse see-also should be generated as well.

    Carp, ... Lots of references ...
      See also Goldfish <-- because an index-see to Carp was converted
to an index-see-also

    Goldfish, 34
      See also Carp

This is not the case for an index-see that is not converted because the
index-see could be from a deprecated term to an approved term.

Best wishes,

Bruce

-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Tuesday, October 03, 2006 10:04 AM
To: dita@lists.oasis-open.org
Subject: RE: [dita] treating index-see as index-see-also

 

> -----Original Message-----
> From: Esrig, Bruce (Bruce) [mailto:esrig@lucent.com]
> Sent: Tuesday, 2006 October 03 08:54
> To: Grosso, Paul; dita@lists.oasis-open.org
> Subject: RE: [dita] treating index-see as index-see-also
> 
> Do we have a set of scenarios in which it makes sense to treat an 
> index-see as an index-see-also? I tried to construct one, and had 
> difficulty.

Sure.

You've got an index-see for "Goldfish, see Carp" in a topic that is
referenced in your bookmap, and you generate output including an index
and all is well.

Then you decide to reference one more topic from your bookmap, but it
happens to have an indexterm for "Goldfish".

So now you're generating an index where you have "Goldfish, see Carp" as
well as a page number due to the indexterm, but it is incorrect to have
a "See" and a page number.  If you instead treat the index-see as a
see-also, you would get a valid index entry.

I don't quite understand the rest of your message.

paul

> 
> The question has to do with the root cause for the clash. Is the root 
> cause a disagreement (or unintentional inconsistency) over what term 
> to use? Is it an erroneous use in one place compared with another?
> 
> A viable scenario should show a sequence of source materials being 
> processed, an intended behavior implemented by processing, and the 
> resulting output. There would need to be more than one scenario in 
> order to show different ways that a clash could arise.
> 
> Best wishes,
> 
> Bruce Esrig
> 
> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Monday, October 02, 2006 4:28 PM
> To: dita@lists.oasis-open.org
> Subject: [dita] indexterm proposed wording
> 
> Proposed additional wording for indexterm.
> 
> > -----Original Message-----
> > From: Grosso, Paul [mailto:pgrosso@ptc.com]
> > Sent: Tuesday, 2006 September 26 11:37
> > To: dita@lists.oasis-open.org
> > Subject: RE: [dita] review of index* elements
> 
> > > indexterm
> > > ---------
> 
> > Issue:  What if an an indexterm contains both an index-see and an 
> > index-see-also.
> > 
> > Proposed resolution:
> > 
> > It is an error if an indexterm contains both an index-see and an 
> > index-see-also.  An implementation may (but need
> > not) give an error message, and may (but need not) recover
> by treating
> 
> > the index-see as an index-see-also (in which case the page number 
> > where the index-see-also occurred will also appear in the index 
> > entry).
> > 
> > ACTION to Paul:  Provide suggested wording.
> 
> Add as the final para of the first section:
> 
> It is an error if an indexterm containing no indexterm children 
> contains both an index-see and an index-see-also.  (Note:
> index-see and index-see-also elements within indexterms that do 
> contain indexterm children are ignored.)  In the case of this error 
> condition, an implementation may (but need
> not) give an error message, and may (but need not) recover by treating

> all such index-see elements as index-see-also elements.
>