RE: [dita] Proposed index range revisions (was Re: [dita] Are indextermranges backwards incompatible?)

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Index Enthusiasts:

For what it's worth, Sperberg-McQueen asserts that an XML specification should "get the key things down in writing without over-restricting things, without over-emphasizing the orderliness that we perceive, without filtering out signal unintentionally." [1]

Trying to keep that judicious big picture for the indexing question, I would think that we should:

• Make it easy to indicate _what_ is indexed but leave output decisions up to the process within reason. (In other words, allow a process to emit a page range if an indexed topic spans 20 pages or if 3 continguous topics are indexed with the same term.)

• Accept that indexing has an implicit ambiguity and allow processes to interpret an index both as a point / span over the flow for purposes of determining page numbers and as a semantic assertion about the container of the index item.

• Rely on specialization to distinguish different types of index items (especially differences in semantics).

Part of the challenge is that indexing is partly contextual (as Paul Prescod has pointed out [mails coming in faster than I can type]):

• A topic might have the most important treatment of a subject in one deliverable but not in another.
• The best term for the subject may be different in one deliverable than another. For instance, I might need to change the term from "selection" to "query" depending on the other topics and the terms they use or based on the audience. Moreover, I'd like to make that change in one place for all of the topics in the deliverable.

In DITA, the representation of context is the map, which suggests meeting these requirements through the map.  However, the positioning of index points and ranges with respect to the flow is clearly best done within in the topic.  Moreover, when I reuse a topic, I don't want to have to reconstruct its indexing in each context.

Also, DITA would benefit from a continuum of use -- being able (but not required) to scale up to a rigorous separation of term from its sense (taxonomy, here we come).

In short, we defined DITA 1.1 as the simple cut back in February and have many tough questions remaining that might best be attacked as a whole.

For explicit ranges, my main concern is that we avoid multiplying DITA referencing mechanisms.  If we're confident that we aren't introducing a constraining legacy, I'm happy with keyref.


Hoping that's useful,



Erik Hennum
ehennum@us.ibm.com


[1] http://www.idealliance.org/papers/extreme/proceedings/html/2005/SperbergMcQueen02/EML2005SperbergMcQueen02.html