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

DITA in itself has no intrinsic teleology. What it "should" do depends on what its users want it to do. Best I can tell, nowhere have we decided that DITA should not be used for print-centric deliverables. What I can say is that DITA has gaps in its support for books: gaps that the TC can fill. The interest in bookmap/bookinfo demonstrates this, as Erik Hennum said. I say that we can fill in the indexterm gap too, without too much work. 

If we are going to have a policy of discouraging print-centric use of DITA, I suggest this be made explicit. I suspect many on the TC would disagree on such a limitation.


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

Chris Wong wrote:

> My point is that we cannot assume DITA adopters will not be
> print-centric, nor can we tell print-centric users to bugger off.

I think this is the disconnect: DITA is explicitly *not* print centric. 
It was originally designed to do things that *were not books* and what 
facilities it has for doing book-type deliverables are, while not an 
afterthought, definitely not the primary focus of its design.

What I'm saying is that some users of DITA may have made a suboptimal 
technology choice if sophisticated book-centric publishing is a primary 
requirement. That's just a fact and their inappropriate choice doesn't 
necessarily obligate us, as a standards development body, to reorder our 

As a standards development body, just like any other development group, 
we have to carefully manage the scope of what we're doing. DITA has 
clearly defined, from the beginning, that sophisticated book publishing 
is outside its scope. To the degree that holding that line means telling 
some users to "bugger off" then we have to do that. DITA can't be all 
things to all users. DITA will always be under presure to add features 
that are outside of its scope. Sometimes we have to make hard decisions 
about what to take on and what not to take on.

But at the same time, DITA can be extended unilaterally and I think that 
sophisticated indexing is exactly the place to take advantage of that. 
If there is a community of DITA users who really need more indexing than 
DITA can easily provide with a minimum of design effort, that community 
can drive its own development activity, whether its within a single 
enterprise or an ad-hoc collaborative effort: i.e., start a project on 
Source Forge.

In the case of Idiom as a business, a business that is explicitly 
selling DITA-based solutions (see www.idiominc.com), I see an 
opportunity to offer additional value by providing a well-architected 
indexing solution on top of core DITA. But just because a company like 
Idiom or Innodata Isogen, both companies that try to sell DITA-based 
products and services, have customers that have requirements that DITA 
doesn't currently meet doesn't necessarily mean that those features have 
to go into the core DITA design. Precisely because of DITA's inherent 
extensibility we, as a marketplace, can offer value-added solutions, 
some of which might eventually become part of core DITA, some of which 
might not.

Sophisticated indexing is just one example of a requirement that core 
DITA will not ever satisfy. But DITA provides a built-in mechanism for 
those requirements to be satisfied by third parties in an architected way.


W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8841


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