[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] some index-range-* issues
I would not call a practice codified in the Chicago Manual
of Style as "bad practice". Index page ranges, like it or not, is accepted
writing practice.
The whole point of page ranges is to cover pertinent ranges
that do not follow the strict hierarchy of the underlying XML. We've covered
this before, and the proposal's extended discussion contains some of the
reasoning. I wonder if it is necessary to reopen a debate that we have spent
many hours resolving months ago.
Chris From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com] Sent: Tuesday, August 08, 2006 5:47 PM To: Dana Spradley; Grosso, Paul Cc: dita@lists.oasis-open.org Subject: RE: [dita] some index-range-* issues Dana, You’re echoing my
thoughts, reflected in this earlier memo. Perhaps
the additional confusion here is moving across topics. It would seem better to
avoid cross-topic indexing ranges completely. Would that still be an option?
I
think the current state of the proposals in both cases tries to
accommodate poor indexing practices that ignore the usability of an index for
actual readers. The simplest method is to give the page number only for the
first page of a longer item, letting the reader decide when he has had enough.
Some indexers use ff (folios or numbers of pages)to indicate a longer
discussion, beginning on a page, such as 356ff with the ff in italic. There is
something problematic, it seems, to have page ranges that span topics, given our
case for the standalone nature of a topic. Anyway
-- just a few thoughts on the philosophy behind the technical
debate. JoAnn JoAnn T. Hackos,
PhD www.comtech-serv.com From: Dana Spradley
[mailto:dana.spradley@oracle.com] Even after this morning's discussion, I like Paul's idea
- although I personally wouldn't allow mixed content in index-term-start, but
would wrap the top-level indexterm in an indexterm element. I'm resending this email to the list since it never made it. I have deleted some parts that are no longer at issue. I hope to follow up with another email with another proposal.
Issues ======
The currently proposed index-range-* elements are just empty "flags" that get put inside an indexterm element. But it is not necessarily clear what this means in the case of nested indexterms.
For example, per my best understanding, one way to indicate a page range for my "pecorino" example would be markup such as the following (where the comments just indicate what pages each indexterm falls on):
. . . <!-- page 22 --> <indexterm>cheese <indexterm>sheeps milk cheeses <indexterm>pecorino<index-range-start/></indexterm> </indexterm> </indexterm> . . . <!-- page 24 --> <indexterm>cheese <indexterm>sheeps milk cheeses <indexterm>pecorino<index-range-end/></indexterm> </indexterm> </indexterm> . . .
But what if the <index-range-start/> is placed elsewhere in the first indexterm, such as:
<!-- page 22 --> <indexterm>cheese<index-range-start/> <indexterm>sheeps milk cheeses <indexterm>pecorino</indexterm> </indexterm> </indexterm>
Is that equivalent, does it mean something else, or is it an error? (My best guess is that it should be equivalent.)
What about the following:
<indexterm>cheese<index-range-start/></indexterm> . . . <indexterm>cheese<index-range-end/> <indexterm>sheeps milk cheeses </indexterm> </indexterm>
Since the first is an index reference for "cheese" and the second is one for "cheese;sheeps milk cheeses", my best guess is these two do not constitute a matched pair.
What about the following:
<indexterm>cheese<index-range-start/> <indexterm>sheeps milk cheeses<index-range-end/> </indexterm> </indexterm> . . . <indexterm>cheese<index-range-end/> <indexterm>sheeps milk cheeses </indexterm> </indexterm>
Is the first indexterm a range start or range end (or just an error)? If it is a range start, does it end immediately, or is its range-end ignored, and the range is ended by the subsequent indexterm?
None of this is made clear in the current writeup.
Also, I think this is very confusing and error-prone for users.
Potential solution ==================
Rather than having empty index-range-* elements that magically redefine their parent to have different semantics, I think it would be preferable to have a specialization of indexterm (or just another element) that can be used to indicate the start of a range--so we would write something like:
<index-range-start>cheese <indexterm>sheeps milk cheeses <indexterm>pecorino</indexterm> </indexterm> </index-range-start>
to start the "cheese--sheeps milk cheeses--pecorino" range.
While in theory we could then have an analagous index-range-end element with the identical nested indexterm content, I think that is another mistake in the current proposal. The idea of creating matching pairs by having to have identical content has already been pointed out as a translation nightmare, but when you start to consider nested indexterms, it's an even worse error-prone mess, both for the user and the implementors.
Instead, I would add an NMTOKEN attribute to both index-range-start and index-range-end, and have index-range-end be an empty element that just refers back to the start:
<index-range-start subject="pecorino">cheese <indexterm>sheeps milk cheeses <indexterm>pecorino</indexterm> </indexterm> </index-range-start> . . . <index-range-end subject="pecorino"/>
The "subject" attribute would act like a sort of id/idref, but I've avoided really using IDs, because then if you have two ranges that discuss "pecorino", you couldn't reuse the id="pecorino".
paul |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]