DITA: It's Just XML

I've been talking for a couple of years now about the value of the DITA standard (http://dita.xml.org/standard) for publishers. I've also implemented several DITA-based applications for publishers in the last few years.

But there still seems to be a lot of confusion and misinformation about DITA, judging by comments I got at the recent RSuiteCMS User Conference. One person came up and said "DITA looks like it would really apply to our content but another vendor told us 'DITA is for TechDoc'", to which I replied, "Not at all, DITA is very likely a very good fit for your application."

In fact DITA is completely and compellingly applicable to almost any situation where XML is used for authoring and managing documents intended for consumption by humans, e.g., books, journals, reports, Web pages, etc.

But it can be hard to see that amid all of the stuff that gets said about DITA.

DITA is a sophisticated application architecture with lots of very useful features. People coming to DITA or promoting it, especially in the TechDoc world, tend to focus on the most sophisticated features because they're focusing on business problems for which those features are intended, such as managing large bodies of small re-used information modules across information for many products (for example, mobile phone manuals). That's cool stuff, but it's also pretty complex. It's no suprise that people see in-depth discussions of DITA maps and re-use strategies and localization best practice and say "hold the phone, I just want to get my traditional documents into XML I can understand--I don't need all this fancy stuff."

I'm here to say: you're probably right, you don't need all that whizbang stuff (today), but don't be so quick to reject DITA as a potential solution base.

If you ignore all of the features of DITA that get the technology guys like me excited, you start to see that DITA has two important aspects that tend to get overlooked:

1. At its core DITA is very simple and can be easily applied to simple XML applications that just need to represent things like books and magazine articles.
2. DITA's unique extensibility architecture makes it a much better business value than any comparable XML alternative.

There's lots to say about this, but the short version is that, because of unique features of the DITA architecture, it is both as easy as it could possibly be to develop custom DITA-based XML document types and as easy as it could possibly be to implement authoring and processing for documents using those document types. And the cost will tend to go down over time as more and more XML-aware products and tools become fully DITA-aware.

That is, DITA's unique features, in particular the "specialization" feature, have the effect of keeping both the initial implementation cost of a DITA-based solution and the ongoing, long-term cost as low as it can be for any XML application.

This is a significant benefit irrespective of any other technical benefit DITA might provide in terms of cool features, simply because it means you can, for example, move to or experiment with an XML-based process with a minimum of initial implementation cost, simply because DITA makes it so easy to do. At the same time, even though you're using a standard XML application, you can still create markup that is as optimized for your specific documents and business processes as you care to make, from not all to every tag is specific to you, all within the framework of the DITA standard, without making interchange or processing harder or more expensive.

For example, you could easily define a DITA-based document type intended to represent entire books (or more likely, entire chapters) as single XML files. This is about the simplest way to usefully apply XML to publishing applications and is a pretty typical starting point. The DITA standard completely supports this straightforward use of DITA, even though it's not using DITA maps or any other of the features that people tend to focus on.

Having done this you would have exactly what you would have gotten had you created a document type from scratch or used a standard like DocBook or NLM as your base, except that you would have gotten a bunch of stuff essentially for free:

• A lot of commercial tools would "just work" with your content with little or no additional configuration, regardless of how custom your tags are.
• You spent a lot less on the initial implementation than you would have spent on any other way of getting to the same place (especially if you wanted fairly customized markup).
• You are ready to start using any of the more-sophisticated DITA features you need at any time, as it makes business sense to do so, but not before.

In short, you will have an XML application that, on its surface, is just another XML application like any other, and if the fact that it happens to be DITA-based is not interesting or helpful, you don't need to mention it. It's just XML.

But if it being DITA is useful, then because it is DITA-based, anyone who already understands DITA knows a whole lot about your XML application, just because it is DITA-based. And when you find that you do in fact have a compelling business requirement to make your content more modular or create new products simply by creating new maps over existing content, you're set to do it with minimum additional effort, without having to have stepped up to that level of complexity as a cost of entry.

As somebody who is both a technologist interested in doing cool things with information and pushing the state of the art and a service provider who wants to provide the most appropriate, highest-value solution to my clients (which means appropriate features for now at the lowest cost without sacrificing future flexibility or building in hidden costs), I find this aspect of DITA very exciting.

I see DITA as a way to make XML much more realistically accessible to enterprises, large and small, that have compelling business reasons to use XML but for whom the traditional (pre-DITA) cost was often prohibitive, or at least daunting. In a time when economic presures are simultaneously requiring Publishers to innovate and squeezing the budgets used to deploy that innovation, I see DITA, simply in terms of its economy, as a powerful tool that Publishers can apply, even for what may seem to be simple problems.

If anyone says to you "DITA is too complicated for your needs" or "DITA is only for TechDoc" you tell them to talk to me, because they are misinformed.

DITA is just XML, plain and simple.

Comments

[Bob DuCharme]

Hi Eliot,

For "commercial tools [to] 'just work' with your content with little or no additional configuration, regardless of how custom your tags are" you must take advantage of specialization, but it seems to me that lot of people go on about the benefits of DITA without really understanding this, thereby taking the "just XML" bit a little too far--they're pushing many benefits of DITA that have been around since SGML DocBook (more on this here).

For example, note how Madcap software goes on and on about their DITA support, but how this shows that the word "specialization" doesn't appear anywhere on their website. (They have not responded to a 10/30 email asking about specialization support.) I was also surprised at how the CMSWatch "XML & Component Content Report 2008" (plugged by Bob Glushko here) described DITA specialization in terms that made it sound no different from the customizability of DocBook or XHTML 1.1, missing the point you bring up that DITA lets you process customized content with software that knows nothing about the customization.