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.
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.