In this exclusive TheContentWrangler.com interview with Rick Schochler of Innodata Isogen, Scott Abel talks to Rick about his company’s experience working with the Darwin Information Typing Architecture (DITA). While he and his firm see DITA as an excellent “option” for some organizations, he advises readers to maintain a “healthy skepticism” when it comes to software tools and their “support” for DITA. “Some day we’ll have tools that will provide some default functionality,” Schochler says. For those who, for whatever business reasons, decide not to move to DITA, Schochler has this advice: “Get your data in a tool-neutral format (XML), then choose the content structure approach that best fits your requirements.”
TCW: Tell us a little about yourself.
Innodata Isogen: I’ve been with Innodata Isogen since 2000, with a brief hiatus in 2003-2004. Presently, I am a Senior Analyst, Technical Lead, and Project Managerdepending on the day and the hour.
TCW: When did Innodata Isogen first get involved with DITA?
Innodata Isogen: Almost from the start. We’re a member of the OASIS DITA Technical Committee and we helped to define the standard for DITA 1.0.
We’ve also been implementing ‘DITA-like’ solutions (i.e., topic-based, modular approach to authoring) for years. So, supporting DITA was an easy decision. The fact that there are now standards such as DITA and S1000D simply means that we often have a more informed customer when we begin the process of implementing their system, and that some day we’ll have tools that will provide some default functionality.
DITA is a good choice for our customers who want to take a modular approach to authoring technical data. And, I particularly like the fact that the DITA Specification does not attempt to be all things to all people. Instead, you are provided with a compact structure, and allowed to specialize that structure to suit your purposes. I believe this is precisely where the DITA folks got it right and it’s one of the reasons that I’m recommending DITA to some of our customers.
With that said, I don’t believe that anyone here feels that DITA is the “only way” to author technical data. Many of our customers, for very sound and rational reasons, prefer to continue authoring their content in a traditional manner. Others still, due to their particular field or industry, are required to conform to another specification. That’s fine. The most important thing, is to get your data in a tool-neutral format (XML) then choose the content structure approach that best fits your requirements.
TCW: On what documentation (content) has Innodata Isogen used DITA to help a client?
Innodata Isogen: Quite frankly, most of our customers are in the information gathering stage when it comes to DITA. We are implementing a DITA solution for a government agency, not because they asked for it by name, per se, but because their data and their business processes were absolutely ideal for DITA (information easily maintained as topics, and their authors were already comfortable with a modular approach to content creation). We are also in the early stages of implementing DITA-based solutions for two customers who specifically asked for a DITA-based management system for their technical data which goes back to my earlier statement about a more informed customer.
TCW: Did Innodata Isogen have to specialize (customize) DITA to help the client meet its goals? If so, what did you need to specialize and why?
Innodata Isogen: For the aforementioned government agency, yes, we did choose to specialize. The primary reason is that they wanted the tags surrounding their data to accurately describe that information.
TCW: What lessons learned can you share with readers about specializing DITA?
Innodata Isogen: Don’t be afraid to specialize, but have a rational and documented reason for your decision. That’s it. Oh, and don’t assume that tools can do much with your specialized topics yet. We know the promise default formatting, rendering, etc. of your specialized elements. But, by and large, the tools aren’t there yet. That doesn’t mean it isn’t worth specializing, just maintain a healthy skepticism when it comes to current tool support for DITA.
TCW: Why didn’t you just use Microsoft Word to create DITA content?
Innodata Isogen: Well, using programs like Microsoft Word to create DITA violates the more fundamental and aforementioned tenant: Keep your data in a tool-neutral format. Also, one of the key requirements that most of our customers have is to achieve single-source publishing (one source document, with multiple output formats). This can be a difficult requirement to achieve if maintaining data in Word.
TCW: What benefits did DITA provide Innodata Isogen over the old way of creating content?
Innodata Isogen: The answer depends upon what you mean by the phrase “old way of creating content.” As I said earlier, we’ve been implementing topic-based systems for our customers for years. The benefit that DITA provides is an established community of people who are tackling the same issues, a well thought-out standard, and tools that will eventually provide support for all the cool things that DITA promises.
If, on the other hand, you mean the traditional means of creating technical documentation where a particular document is created end-to-end, the advantages are typically more philosophical in nature. One of the more subjective arguments I hear as an advantage to using DITA over traditional, linear-based authoring, is that the DITA (minimalist) approach reduces “filler” or transition language. In other words, it makes the author concentrate on the specific task, procedure, etc. without worrying about what has come prior to or is coming after that topic. Additionally, achieving an adequate level of reuse is easier because of the modular approach to content creation. But, I must stress, if your enterprise isn’t comfortable with authoring at the module level, and there isn’t some level of “buy-in” then, there isn’t an advantage to switching to DITA.
TCW: What “lessons learned” can you share with others interested in considering a move to DITA?
Innodata Isogen: There are several things that we tend to mention when asked about lessons learned with regard to DITA: First, get sponsorship from the executive level. Switching to a topic-based authoring environment is a seismic shift. Getting buy-in from as high up as possible will let people on the fence know that the change is inevitable. Second, have a carefully planned, phased process for implementing pilot systems and rolling them into production. Third, communicate! Through all levels of implementation. Finally, develop ahead of time a set of defined and measurable metrics this isn’t poetry define success prior to implementation. And don’t assume that a single tool will solve all your requirements. You will have requirements that the tool(s) you select won’t handle. Know what these are ahead of time and make sure your implementor has a plan for handling these requirements.
TCW: There’s a lot of hoopla surrounding DITA. It’s been over-hyped as the cure-all for many content problems. Can you think of any content types that would not lend themselves to DITA and why?
Innodata Isogen: DITA is not designed to be a cure all. It is geared toward data that is modular in nature. As such, information that is not at all modular or that is primarily narrative in nature or stuff like marketing information, data sheets, and so on is clearly not much of a candidate for DITA.
TCW: Are there any issues with using DITA for print output?
Innodata Isogen: One thing that occurs to me that is germane to DITA is the current lack of tool support for default formatting of specialized elements. However, I expect to see tools start providing such functionality in the coming months. Additionally, there’s no direct support for creating more traditional book structures, especially for non-reference books in DITA 1.0. DITA 1.1 focuses on adding new features specifically to support the creation of more traditional book structures. Other than that, it’s a question of implementing your composition process to the level of completeness you need, just like you would for any other document type.
TCW: Was the content created using DITA translated?
Innodata Isogen: Nope. I’m sure that project will happen, but it hasn’t happened yet.
TCW: How did DITA help with translation?
Innodata Isogen: Well, I can only guess on this, but I can promise an educated guess. I think the minimalist approach to technical authoring, perhaps coupled with the codified rules of Simplified Technical English, could greatly reduce the costs and efforts surrounding translation.
TCW: Does Innodata Isogen plan to use DITA for other projects?
Innodata Isogen: Absolutely. As I stated before, we’re in the early stages of architecting a DITA-based content management system for a couple of our customers. And, though it’s true that DITA is getting a lot of hype at the moment, it is a solid approach for enterprises seeking to author and manage their content as topics. For that reason, we are predicting many more DITA projects in the near future.
TCW: What advice can you share with others who are considering DITA, but aren’t sure it’s right for them?
Innodata Isogen: That’s the best possible question that a group or enterprise can ask: “Is DITA right for our organization?” The best way to answer that is to lay out your business requirement all of them and see if a DITA-centric system is the right solution. If business requirements dictate topic-based authoring, achieving some level of reuse, a minimalist approach to authoring technical data, or some combination of the above, then it’s probably a good idea. If, on the other hand, your requirements don’t match what a DITA environment portends to provide, or you don’t have a significant level of corporate buy-in, you anticipate your writers going into open revolt, you don’t have the varied resources (time, money, people) to thoroughly analyze how DITA will impact how your create and manage your data, etc., then don’t feel bad about going with another option.
TCW: Is it possible to move to DITA and really mess things up?
Innodata Isogen: Sure, but it probably won’t be because of DITA. Even if not all of the functionality is realized, it’s really hard for a DTD to completely mess up a system. If things do get messed up, it boils down to this: Not all your business requirements were met and they were probably some really important ones. That can happen for a variety of reasons: Sometimes business rules are unintentionally left out due to lack of a thorough analysis process at the outset. Or, the tools selected didn’t do what they promised.
TCW: If you had a DITA wish list, what functionality would you add to DITA and why?
Innodata Isogen: Nothing off the wall. Right now, a lot of companies have slapped “DITA support” onto their existing tools. I’m anxious to see the next phase of support.
TCW: Thanks for sharing your thoughts and experiences about DITA with our readers today, Rick. Where can folks who want to know a little more about Innodata Isogen find out what services you offer?
Innodata Isogen: Thanks for the opportunity, Scott. Your readers can visit our corporate website, http://www.innodata-isogen.com where they can find all sorts of useful information. If they’re got questions, they can contact me directly via email at rschochler@innodata-isogen.com
