The mechanism is standard index page number merging.
This is the way most standards that speak of indexing and most indexing tools
that I have seen in the last 25 years work.
Our implementation allows users to specify the minumum
number of consecutive page numbers before merging into a range in the result (or
to turn off merging altogether). The default is 3, and few customers
change that. Our customers would certainly complain if we did no automatic
page number merging.
paul
I would not agree
with the result assumptions. What mechanism exists for the numbers 5, 6, 7,
and 8 to be concatenated into a range 5-8? A continuous discussion
ranging over pages 5-8 does not mean the same as points referenced by the
number 5, 6, 7, and 8. The indexer should be solely responsible for
determining when a range of pages is used, not have some automatic decision
made.
JoAnn
JoAnn T. Hackos,
PhD
President
Comtech
Services, Inc.
710 Kipling Street, Suite
400
Denver, CO
80215
303-232-7586
joann.hackos@comtech-serv.com
joannhackos
Skype
www.comtech-serv.com
I generally agree with Bruce
here.
But I also need to
take issue with:
new ranged indexterms they add
would cause these old point indexterms to be
misinterpreted
With our existing
indexterm markup, you cannot distinguish between use of indexterms and ranges
by looking at the resulting index. An indexterm marks a point, and the
page on which that point falls will be included in the resulting
index. An index range marks a start and end point, and all pages starting
with the one on which the start point falls and ending with the one on which
the end point falls will be included in the resulting
index.
Unless one has a
fancier indexing process whereby one can, say, request a bold page number in
the index for the most important reference and italic page numbers for pages
on which there are related figures, etc., there is no distinction among page
numbers in the resulting index.
Looking at the
resulting index, one cannot tell if index-page-range markup was used to create
that index or not. A resulting index entry of:
cheese 2, 5-8,
12
could have been
generated by pointwise indexterm markup throughout the source that just so
happened to end up being points on pages 2, 5, 6, 7, 8, and
12.
paul
From:
Esrig, Bruce (Bruce) [mailto:esrig@lucent.com]
Sent: Tuesday, 2006 August 15
11:53
To: Dana
Spradley
Cc:
dita@lists.oasis-open.org
Subject: RE: [dita] Are indexterm
ranges backwards incompatible?
On the other hand,
Dana,
This logic could be
applied to outlaw any extension, since every user would have to review every
document to determine whether they had intended to use the
extension.
With DITA 1.1, we
clarify that an indexterm designates a point at which to start reading about
the indexed subject. The DITA 1.1 conceit is that this was true all along.
In DITA 1.0, this aspect of the interpretation was unspecified because there
was no way to specify anything else. But if it even makes sense to take
sides on this, it's possible to argue that the default disambiguation is the
DITA 1.1 way. Indexing practice typically presumes that an index entry
refers to a point at which to start reading.
For those who wish
to specify a range of pages possibly not starting at the top of a
topic, a new capability is provided that permits such a specification. The
specification of a range generates a page range in outputs that have page
numbers, such as PDF files. In other outputs, it generates a reference to
the start page only.
Best
wishes,
From:
Dana Spradley [mailto:dana.spradley@oracle.com]
Sent: Tuesday, August 15, 2006 12:41
PM
To:
dita@lists.oasis-open.org
Subject: [dita] Are indexterm ranges
backwards incompatible?
After this morning's meeting,
I'm starting to think that maybe ranged indexterm should be considered
backwards incompatible with DITA 1.0.
In 1.0, it is ambiguous
whether indexterms point to discussions confined to a single page, or to
extended discussions that begin on a certain page.
Introducing
ranged indexterms removes that ambiguity.
Users who want to make
use of ranged indexterms would need to go back through their entire
document set and replace current point indexterms with ranged indexterms
where appropriate - otherwise any new ranged indexterms they add would
cause these old point indexterms to be misinterpreted.
Doesn't that
amount to backwards
incompatibility?
--Dana