RE: [dita] review of index* elements [was: DITA 1.1 Language Specification -- draft (ditaref-alpha.pdf) uploaded]

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

I have answers for some of your questions ...

For index-see/index-see-also, the rule I recall is that if you have an
index-see but another index entry generates a page reference, the
index-see is treated as a see-also.

For your index-sort-as question, a single
<index-sort-as>apple</index-sort-as> at the highest level should cover
the entire index entry, causing "$apple" to be sorted as "apple". If
index-sort-as appears at a lower level, it would affect the sorting of
the value at that level only. If that doesn't answer the question, then
more examples might be needed.

The "ignore unless a leaf" criterion wouldn't seem to apply to
index-sort-as, since its function is to affect processing of a value,
not to create a new index entry.

Not addressed in this response: the "global sort order" and "maximum
range" issues.

Best wishes,

Bruce

-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com] 
Sent: Wednesday, September 20, 2006 11:49 AM
To: dita@lists.oasis-open.org
Subject: [dita] review of index* elements [was: DITA 1.1 Language
Specification -- draft (ditaref-alpha.pdf) uploaded]

index-see
---------
The description doesn't make clear when a see becomes a see-also and
vice versa or whether there are error cases and/or when we ignore one in
favor of the other.

index-see-also
--------------
Will the "Content reference to..." in this description actually become a
content reference in the next draft?

The description doesn't make clear when a see becomes a see-also and
vice versa or whether there are error cases and/or when we ignore one in
favor of the other.

indexterm
---------
In the first bullet point ("In a map..."), there remains a question
("???") about how to define the maximum scope of a range specified in a
map file.

index-sort-as
-------------
There remains lots of issues about "global sort order" 
using indexterms within the prolog.  For one thing, this contradicts
other decisions we made about what an indexterm within the prolog means.
See also my email of July 26:
http://lists.oasis-open.org/archives/dita/200607/msg00076.html
with other questions/issues about sort-as that have never been answered.

Furthermore, it isn't clear to me how to use sort-as for a multilevel
index term.

It is unclear how to handle the "ignore unless a leaf" 
issue for index-sort-as.

paul