Category Archives: standards

DITA in Review

I’ve been thinking about DITA, partly because of the comments from Michael Priestley regarding my previous DITA post, but also because I recently had to prepare a quote for a prospective client.

On one hand, I still maintain that a generic structure can practically never be as immediately relevant to a client than a structure tailored for their needs. I’ve seen this happen many times in the past, having to compare various so-called industry standards with the actual needs of my clients. Structures have mapped poorly, which is to be expected, but the same has been true with meta-data which, in a way, is more surprising, considering that meta-data should be something the industry standards get right.

On the other hand, recently, after my latest DITA blog, a prospective client requested a quote for replacing their current CMS. They’ve been authoring topic-oriented pieces of information for online publishing, with the topics sometimes collected in larger PDFs printed out and placed in binders. What they wanted was better version handling, integration with PDM applications, and an environment that would better support the authoring of individual topics published in various contexts. There was very few obstacles in the way of company-specific structures or meta-data.

Individual, loose topics, published in various contexts and deliverables, mostly online, sometimes on paper but as collections in binders. Hmm… where have I heard this line of thinking before?

Knowing how several editors out there have feature-rich DITA support and are easily adaptable, the quote was quite easy to prepare. It’s certainly easier to offer a figure when many of the unknowns are already taken are of, and this one practically screamed DITA.

Maybe the RFQ was a practical joke from the DITA folks. You’d tell me, right?

DITA

For the last year or three, XML editor makers have been busy coding DITA customizations into their products. The latest editor to get DITA is Oxygen, my XML IDE of choice these days. It’s the latest fad, see, and there’s money to be made.

But I’m not convinced, and here’s why:

DITA claims to make life easier for users by splitting documents into smaller, reusable pieces, hinting that this is a fresh, new approach to documentation. It’s not, however; some of us have done this for years in our DTDs, long before XML was even thought of, simply because that’s one of the main points with structured information. It’s the sensible thing to do, a good reason to why structured information is useful in the first place.

Now, this is all good and well, but because DITA needs to appeal to a lot of users, it is a generic structure, and it’s big. Both of these things are unfortunate since bigger means more difficult to learn, both for users and developers, and generic means that to apply the structure to your specific needs, an abstraction (customization) level is needed.

Generic also means that any markup specific to one user’s needs will have to be added, which means more customization.

With DITA comes a package of stylesheets and utilities, also big and generic, hard to learn, and in need of customization, not only to add the user-specific requirements, but also to modify their look and feel. After all, you don’t really want to have your documents look like the next guy’s, do you?

See, what the DITA advocates are saying, basically, is that either you do want that, or you need to customize.

My view of document structures is just the opposite, really. I’d much rather go with writing a customer-specific DTD, if at all possible, just as I’d go for customer-specific stylesheets and other customizations and tweaks. In that way, I could make the structures, utilities, and stylesheets immediately relevant to the customer, thereby saving time spent trying to learn a generic structure and then trying to apply it to your needs.

That customer-specific DTD will practically always be smaller than any generic one; I know every single DTD I’ve ever created has been, including the package of DTDs I wrote for a large automobile manufacturer for all of their aftersales documentation. At the same time the DTD will most likely be far more relevant, far better fine-tuned, for the customer’s needs.

And yet, it would be just as easily customizable as DITA or some other “standards-based DTD“.

When I’m lecturing on XML and document structure management, I always stress that we use XML because we like to convert XML to other formats, not because we want it to remain the same. If some other company needs DITA documents from us, fine! I doubt it, but if the need arises, it’s easy, even trivial, to convert a customer-specific structure to a generic one.

See, DITA to me is just another DocBook. It’s a standard, true, but it’s just another standard among a thousand other standards. It’s open, also true, but so are a thousand others. And of course it claims to be easily customizable, but that’s obviously the case with those thousand other standards, too.

But it’s also big and generic and not very relevant as such to any specific requirement, not without an abstraction level or two.