The mantra of XML is that you separate content from formatting. Authors do content; formatting happens later. During a panel discussion at last week’s (excellent) UA Europe conference, I realized that this is only half the story.
Too often, the decision to move to XML is made without any consideration of output requirements. With desktop publishing (DTP) tools and help authoring tools (HATs), a moderately competent computer user can control the look and feel of the final output. A lot of XML implementers assume that their DTP and HAT skills will carry over into XML publishing. Halfway through their project, they discover that XSLT, XSL-FO, and DITA Open Toolkit plugins have much more in common with programming than with traditional publishing tools.
And then the complaints start:
Why is this configuration so hard?
I can’t believe that there’s no GUI-driven tool for XML output.
This PDF output is really ugly!
Why should I have to learn XSLT, CSS, and Ant?
Boo-de-fricking-hoo. Anyone who pays even cursory attention to tech comm chatter or knows how to operate that new-fangled Google thing should observe in less than 10 minutes that XML publishing is technically challenging. I have absolutely no sympathy for those who didn’t discover this before they leaped into an XML project.
Expertise in traditional DTP tools or HATs does not necessarily transfer into competence with myriad XML technologies from Ant to XSL. But many organizations try to implement XML and cut corners on the output design phase. This leads to the widespread assertion that XML produces ugly output.
The default PDF output from the DITA Open Toolkit is certainly not very attractive:
But it’s possible to change the formatting:
The decision whether or not to implement XML should include an assessment of the XML publishing problem, and the costs associated with developing attractive output (in-house or with consultants). The fact that a new workflow requires new skill sets should not come as a surprise in the middle of the project.
(Ed. note: Weak attempt at linking the content of this post and highlights of trip to Dublin in the photos below.)
If the cost of creating attractive output from XML is greater than the benefits of moving to XML, then you either settle for ugly output or you do not move to XML.
These decisions should be made strategically, with a solid understanding of the challenges, and not in a mid-project panic.
XSL coding is not everyone’s cup of tea. I wish just more people would realize this before deciding on their XML strategy.