Not too long ago the second edition of the popular DITA for Print was published by XML Press. While she is a colleague of mine at IXIASOFT, she lives and works in the States and we don’t get the opportunity to meet and talk as much as I would like. Luckily, we had the opportunity to get together at the most recent Content Management Strategies/DITA North America conference in San Diego, where she had the chance to promote her new book (as you can see in the picture!) In addition to co-presenting with me on Markdown and Lightweight DITA, she was proudly signing copies of her new book at the XML Press booth.
She kindly agreed to an interview about her new book along with what her clients are asking for in terms of XSL work and DITA 1.3 implementations.
DITAWriter: So why the new book? What’s changed with the DITA-OT or XSL that made a second edition a necessity?
Leigh White: The drivers for the new edition of the book were threefold. First, the structure of the Open Tookit changed quite a bit with the 2.x releases and I wanted to explain those changes. In particular, there were a few changes that “broke” 1.8.5 plugins and so it was a given that plugins that were developed based on the instructions from the first edition would need reworking. I wanted to provide those instructions. Second, I wanted to address PDF customizations for some of the new DITA 1.3 features that have default processing in the Open Toolkit. Third, I needed to correct an egregious error I made in the first edition, which was to recommend copying entire stylesheets from the default PDF plugin into custom plugins. That was terrible advice and I was rightly criticized for it!
DITAWriter: Have you seen any significant differences in what people are looking for when outputting their content? Is PDF still the “king” of online content formats?
Leigh White: I don’t think you can say that PDF is “king” of online content formats; I think organizations that need real online features like faceted search are turning to formats that offer those features. I’d hope that fewer and fewer organizations are throwing PDFs up on the web as their primary documentation delivery! But we’ve all been hearing that “PDF is dead” for years now but like a zombie (to quote Carlos Evia) it lives on, so clearly plenty of people still feel it’s a critical need, whether through habit or true user needs assessment. For sure, printed documentation remains a regulatory requirement for many industries. It appears that PDF will be with us for a while.
I think (and this is my opinion based on some offhand conversations) that users expect more from PDF than from web-based outputs in terms of careful, consistent formatting. People are used to HTML content appearing differently in different browsers and their expectations are not lower but perhaps more flexible. However, they expect their PDFs to be consistent across all PDF viewers. To them, it’s a book page… perhaps a more tangible thing than a web page and so they expect perfect headers, footers, cover pages, and Table of Contents. They also expect perfect font sizes, line spacing, and alignment. Image sizing is critical, as is control over table width. It is a given that you’ll customize most or all of these things when you create a PDF plugin.
DITAWriter: What’s the uptake you are seeing of DITA 1.3 features that are reflected in DITA-OT output either directly or indirectly, such as the troubleshooting topic type or something more complex like keyscopes?
Leigh White: You have to divide the DITA 1.3 features into three categories: content, architecture, and hybrid (for lack of a better name!). The content-focused features are things like troubleshooting, XML domain, highlight domain additions, table accessibility attributes, and table output attributes. These new features directly affect output and can fairly easily be manipulated in a PDF plugin. The Open Toolkit has default processing for all of them, although it relies on fallback processing for the troubleshooting topic type. It’s not a stretch to add templates specifically for troubleshooting topics and my book explains how to do that. Obviously, these features are the easiest to understand and to manipulate on the output side and the uptake for them will probably be high.
The architecture-focused features include things like keyscope, ditavalref, and metadata cascade. I expect the uptake for these to be fairly high, but the amount of customization available is very limited. Most of the processing work for these features is done in Open Toolkit pre-processing and is implemented largely in Java so it’s not available for customization via a plugin. I’m not sure it would be a good idea to go changing the processing for these features in the first place. Obviously, keyscope and ditavalref affect output in major ways, and they are complex features that I believe require a dedicated information architect to fully implement and track. This might put them out of the reach for small groups, but you could also argue that small groups might not need them.
At the moment, I’m hearing from a few IXIASOFT customers who historically use ditaval quite heavily, that they are very interested in ditavalref. They particularly like the fact that ditavalref enables them to associate a specific ditaval with a map for tracking purposes (i.e. for re-creating past outputs at a specific moment in time) in a way that was not possible when the ditaval was associated only with the output build, not the map.
So far, I’m not hearing a lot of customer buzz about keyscopes. I get questions about it but I don’t think many customers have implemented it. My guess is that this is because groups that have been using keys found ways to architect maps that accommodated the DITA 1.2 one-definition-per-key-per-root-map limitation and are happy enough carrying on with those solutions—for now, anyway.
The hybrid features are those that you might choose to include in output, but not necessarily. These include release management metadata and context-sensitive help. The Open Toolkit doesn’t include processing for these features because they are likely to be implemented in very specific ways. They might also depend on additional tools; for example, the context-sensitive help feature defines window types and context id strings that only become meaningful when implemented in an online help tool. The uptake for these depends on individual groups’ needs and the availability of resources to create appropriate processing for these elements and attributes.
For a previous interview where she discusses her first book and how it came to be, see here.
The book is available directly from XML Press, or from Amazon.com.
