OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] index terms

I'm afraid I will have to disagree rather strongly here. All Idiom's XML publishing customers, including DITA adopters, consider indexing to be high priority. Books (i.e., PDFs) are their PRIMARY deliverable. The functionality I listed in issue #45 are precisely the functionality for which we have had to build non-standard extensions for.

My point is that we cannot assume DITA adopters will not be print-centric, nor can we tell print-centric users to bugger off. They cannot bugger off. They are already here, they have set up shop, thrown lots of money at DITA, and are here to stay. We cannot tell them "don't do page ranges", because they are already doing this. We cannot tell them "don't use sort order expressions", because they are already doing this. They need this stuff, they are doing this stuff, and they are doing it even now.

The danger is that if we refuse to extend DITA to address real-world needs, the real world will build those extensions themselves in many wonderfully incompatible ways. Let this Babelization go too long, and DITA's interoperability promise will evaporate. DITA's missing indexterm functionality is one major area where that can happen. 


-----Original Message-----
From: Eliot Kimber [mailto:ekimber@innodata-isogen.com]
Sent: Monday, October 03, 2005 10:27 AM
To: dita@lists.oasis-open.org
Subject: Re: [dita] index terms

Erik Hennum wrote:


However, having said that, it's difficult for me to imagine that few, if 
any, DITA users would actually eat the expense of doing indexing that is 
this sophisticated. Given the relatively low retrieval value of 
back-of-the-book indexes for information delivered primarily in 
electronic form it's difficult to see that an authoring group would 
choose to invest its limited resources in indexing rather than some 
other, higher-value aspect of the information.

Any publication group that cares that much about indexes is probably a 
print-primary group for whom DITA is not an approprate choice in any case.

Therefore, I do not see any compelling reason to try to design an 
explicit index range mechanism for DITA, at least not one that can span 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]