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.
On the other hand, what is an index range supposed to mean when you
come across one in an index?
I always thought it meant that's where an extended discussion of that
topic occurs in the book.
DITA being a topic-oriented architecture, it would seem more
appropriate to put indexterms that apply to the entire topic somewhere
in the metadata for that topic - and only construct index ranges for
those.
--Dana
Grosso, Paul wrote:
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