Interview with Leigh W. White of DITA for Print

An Interview with Leigh W. White
An Interview with Leigh W. White
Recently I had the honour and opportunity to interview Leigh W. White, author of the recently-published DITA for Print from XML Press. In addition to having authored this book she also works for the DITA CCMS manufacturer Ixiasoft, working with their clients on configuring the system to their needs, and presumably helping out on the XSL front as needed. She lives in Milwaukee, WI and her Twitter profile lists her as being a “DITA geek, writer, reader, thinker, bemused observer”.

Here’s the interview:

DITAWriter: Can you tell me a bit about your background and how you came to start using DITA?

White: I have a Bachelor’s degree in English and a Master’s degree in Theoretical Linguistics, so my educational background is only slightly related to my work. Like so many, I fell into technical writing by accident. I worked with a team of writers at a healthcare IT company, following “traditional” methods of authoring. We wrote content for printed manuals using FrameMaker and content for online Help using Microsoft Word and RoboHelp. Somewhere around 2002, I realized this was unsustainable and began to look at XML. DITA was not yet public and DocBook seemed too much, so I developed a custom XML tagset and FrameMaker structured application. The team was then able to author content once (in FrameMaker), and using ePublisher along with several handy FrameMaker plugins, generate various permutations of printed documentation and online Help. The piece that was missing was that we were still dependent on FrameMaker as a publishing engine because I did not know how to write a complete transform from start to finish.

When DITA became public, I began researching it and realized it was our long-term solution, as it provided a widespread and adaptable standard, flexible (if complex) publishing tools, and a growing community of users on whom I could rely for ideas and support. Around 2008, I developed a Proof of Concept for the team (which included my first, hard-won PDF plugin), sold the team, my boss, and her bosses on DITA, and we never looked back. While the transition was long and not trouble-free by any means, I think we all realized the value of it and were able to look past the short-term issues to the long-term value.

DITA for Print
DITA for Print
DITAWriter: What made you decide to write a book on how to format DITA output using XSL?

White: While developing that Proof of Concept, I found minimal resources to turn to. Or, better said, the resources were there, but they were so scattered between miscellaneous websites, webinars, blogs, magazine articles, conference presentations, and the like, that it was very difficult to bring all of the information together into anything cohesive. I persevered, but I could easily see how many others might become frustrated and give up.

I also saw that a lot of the “how to” information for DITA tended to be very technical and assume a thorough knowledge of XML and XSL. I knew from experience that there were a lot of people out there like me…people who saw the value of DITA and wanted to adopt it. People who were fairly techy but not developers and who needed development resources that spoke to their level of knowledge. There weren’t any such resources for developing PDF plugins for the DITA-OT, so I decided I was as good a person as anyone to create one.

More than anything, I really believe in DITA and want to do whatever I can to promote its adoption. I felt like this was a contribution I could make.

DITAWriter: For you, what is the most frustrating thing about working with the DITA-OT from an output standpoint?

White: Well, the DITA-OT itself can be very frustrating. It’s been developed over a number of years, with contributions from numerous people. It’s been expanded past its original architecture and intent. Everything has to remain 100% backwards compatible, so there’s a lot of old code and a lot of inefficient code. And sometimes, what you expect to happen by default simply doesn’t happen because the developer interpreted the spec differently than you. And of course, there is no GUI for it, so folks who are used to template design in an application like FrameMaker can be completely lost when faced with dozens of XSL files. (There are a few “partial” GUIs, but nothing really robust.) Another frustrating thing is that many vendors seize upon the lack of GUI and Frankenstein nature of the DITA-OT as reasons to dismiss the value of the OT altogether. The persistent rumor (spread by some of these same vendors) that you can’t get professional, completely customized output from the DITA-OT is also frustrating. Of course you can!

DITAWriter: What advice do you have for someone with no coding background wanting to jump head-first into XSL?

White: Take a course, either via a book, online or at a local technical school or college, to teach you the basics. You really need to understand paths and relationships before you can use XSL effectively. Practice writing simple stylesheets to transform basic XML documents. It’s best to start with XML that’s very predictably structured, like an address book, or a catalog of items, or something like that, where every node is identical or very similar. When you’re comfortable navigating through those documents, and getting different kinds of outputs, you can move into XML that’s less predictable, like DITA, where the body of a concept, for example, can contain almost any element in almost any order.

DITAWriter: If you could overhaul anything having to do with the DITA-OT and its current XSL, what would it be (and why)?

White: I would consolidate more of the common templates into just a few stylesheets, rather than having them scattered throughout the OT, and I would parameterize as much as possible. In other words, I would adjust the templates to use more variables and then provide those variables in a single location so that users could make common changes easily and in one place.

DITAWriter: What was the hardest part of this book for you to write?

White: The chapters on headers/footers and page layouts. The process for creating a variable, adding it to the header/footer template, and then adding it to the localization variable is not exactly straightforward. And trying to explain regions and page masters and the associated attributes to users who are probably used to a much more GUI page definition process is pretty thorny. I must have rewritten both of those chapters five times.

DITAWriter: Any thoughts about CSS3 vs. XSL coding?

White: I used to do a bit of work with CSS but not much anymore, and none at all with CSS3. When I first started working with XSL-FO, I was stuck by how similar many of the attributes are. I found my limited CSS experience very helpful when working with XSL-FO. Of course, there are many aspects of XSL, such as selection and processing that are not as much a part of CSS, so while there’s some crossover, XSL programming requires consideration of a lot more details.

DITAWriter: I know some professional programmers who find it hard to wrap their heads around XSL. Why do you think that is?

White: I have no idea! I’m not a programmer and I don’t think like one, so I can’t say what their obstacles are. Maybe it has to do with the fact that XSL relies on XPath, where the “objects” have a specific hierarchical or familial relationship to one another…that’s not usually the case in other programming environments.

DITAWriter: Can you tell us a bit about what you are doing now with Ixiasoft?

White: I joined Ixiasoft in September 2013. At present, I’m working with new customers to help them evaluate their workflows, team roles, etc. and determine how to configure the DITA CMS to accommodate their current processes. I also provide training on the CMS, both end-user and administrator. During the implementation phase, I also serve as a liaison between the customer and our development team to facilitate any custom development that needs to be done to ensure the CMS fully meets their needs. I also on occasion deliver a DITA Workshop to customers who are just beginning to work with DITA and would like a good foundation.

Leigh W. White’s book, DITA for Print, is published by XML Press. It is available there and at


"DITAWriter" is Keith Schengili-Roberts. I work for IXIASOFT as a DITA Specialist/Information Architect. And I like to write about DITA and the technical writing community. To get ahold of me you can email me at:

View all posts by

10 thoughts on “Interview with Leigh W. White of DITA for Print

  1. Thank you Keith and Leigh! I am new to DITA-OT, and I find interviews like these absolutely fascinating. Joel Meier

    1. A pleasure, Joel! Our generous, if motley, community is one of the best things about DITA! Good luck with all your DITA endeavors.

  2. Keith,

    Thanks for the great interview. As Leigh’s publisher, and someone who has spent some time with both the DITA and DocBook stylesheets, I have a couple of thoughts:

    1) It’s worth mentioning that Leigh’s book was written in DITA and the production was all done with the DITA-OT and a plugin from Leigh, so it is possible to do a real book with DITA and the Open Toolkit. We did use RenderX for the FO processing and Oxygen for editing, but otherwise, everything was from the open source world.

    2) Regarding programmers and XSL. I came to XSL from programming procedural languages, like C, where you can take a program and follow a linear path (with looping and choices) through a set of instructions. With XSL, the processor builds a tree from the input, then applies the transforms to that tree, so actually the structure of the input drives the processing. You write programs by creating templates that match things you expect to find in the input tree. Therefore, you can’t take a linear approach to looking at an XSL transform. Once you get the processing model figured out, it works nicely, but it takes a shift in thinking (much like it takes a shift in thinking to deal with object-oriented programming).

  3. I’m reading through Leigh’s book and as a newcomer to DITA, but with some experience in DocBook XSL customization, the book is a necessary compilation of useful tips for coding. It’s a great companion to Eliot Kimber’s DITA book.

  4. Great interview. Leigh hit the nail on the head about some of the frustrations with the OT. As a non-developer myself (and someone who’s had to hack their way through the OT), I look forward to reading her book.

  5. Leigh,
    I appreciate this interview and your comments. I am in the process of having to hack my way through the OT and am having to weed through the dozens of XSL files. Will your book help with understanding where to find these files for the master pages and the associated attributes?


    1. Hi Cynthia…yes, this book will help you do exactly that! One of my goals was to take some of the mystery and intimidation out of that huge pile of files in the OT. Good luck! –Leigh

  6. Hi there,

    this is exactly the book I needed. I started eagerly to read and to create my own pdf plugin. Unfortunately, I stuck in the header/footer chapter. My plugin (as well as the original pdf2 plugin) doesn´t generate footers as it is supposed to, but the example plugin belonging to the book does. Maybe I have insufficient understanding of DITA, but it is hard to find the differences in the stylesheets, if you are not an absolute XSLT crack!

    Anyway, the book is well written and easy to understand, even for non-native speakers.


Comments are closed.