Re: [dita] appropriateness of <dita> root element

[Eliot Kimber <ekimber@reallysi.com>]

Michael Priestley wrote:
> 
> Re:
>  >For meeting notes, white papers, and a host of other things ditabase 
> may be the best practice,
>  >but those users and use cases are not (correct me if I'm wrong) the 
> primary target of the DITA TC.
> 
> The fact that we have an Enterprise Business Document subcommittee 
> suggests you're at least partly wrong. I think the primary target of the 
> DITA TC is modular content, which certainly includes many tech pubs, but 
> extends beyond it.

I think that saying "modular content" is perhaps itself too narrow: I'm 
finding DITA to be quite applicable to content that is not, in the sense 
we generally mean it, modular, or where modularity is not a primary 
aspect of the data.

By the same token, almost all, if not all, documentation-related 
applications of XML have some modular aspect, even if that is not the 
focus (or where DTP brain damage prevents new users from seeing where 
they in fact have modular stuff).

In addition, a focus on modularity does not give full value to DITA's 
specialization features which are, to many, much more compelling than 
modularity.

That is, for users for whom modularity is not particularly interesting, 
specialization turns out to be *very* interesting.

One of the aspects of DITA that I'm only now coming to fully appreciate 
is the degree to which specialization in particular, coupled with the 
existing and growing DITA-aware tools infrastructure, makes using DITA 
the lowest cost of entry and ongoing usage of any possible XML 
application. DITA is, modulo some fixable tools issues, as inexpensive 
as it is possible for a general XML application base to be, and, because 
of its general sophistication, much more valuable than any comparable 
standard (e.g., DocBook), simply because it provides more than DocBook 
(or similar) at a lower cost. Even if DITA cost the same as DocBook to 
use it would be a better value, but it costs *significantly less* than 
DocBook, because of specialization, in particular.

In that light, modularity is just a bonus.

In short, I'm now at the point where, as a consultant, it's to my 
business advantage to use DITA for any XML documentation application 
simply because it makes my job easier (and also lowers the costs to my 
clients).

That has everything to do with specialization and leveraging of 
infrastructure and almost nothing to do with modularity (although I 
certainly take advantage of it where it's needed).

For example, I just started a new project with a client that publishes 
test prep books for U.S. primary school standardized tests.

Even though I had developed a one-off DTD for this client about 8 months 
ago as a proof of concept I threw it away and was able, in three 
calendar days, to implement a from-scratch DITA-based set of topic and 
domain specializations, including the ability to do visual authoring and 
produce demonstrable HTML output. That three days included the time it 
took me to come up to speed on the new Learning specializations, as well 
as the time to create realistic samples by laborious cut-and-paste from 
PDFs of the current publications. The time spent actually creating 
working DTD declarations was maybe four hours max.

Three days. It would normally take me three days just to implement the 
declarations, not to mention configure editors, write enough output 
generators to validate the markup design is sufficient to enable 
rendering, and so on.

Going forward on this project I'll probably spend no more than two or 
three more days on the markup design and declarations (not counting the 
time it will take me to document the specializations, which is the 
largest single time component of doctype implementation at this point).

Just saying....

Cheers,

E.

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com