If you had told me in July 2015 that LearningDITA would have 10 courses and be available in three languages, I wouldn’t have believed you. Since the site’s initial launch, it’s grown from a single course to a major resource for those who need to learn to use DITA.
So you’ve decided to move your content to DITA. You want all the benefits of reuse and less expensive translation, and you’ve completed your content model. But now the question is, “What do we do with our existing content?”
Smart content offers huge benefits to marketing groups. Although using tags and metadata to author content adds an extra step to the process, it’s important to look at the overall value that the step can add.
Structured authoring and XML represent a significant paradigm shift in content creation. Implementing structured authoring with XML allows organizations to enforce content organization requirements. The addition of hierarchy and metadata to content improves reuse and content management. These benefits, however, must be weighed against the effort required to implement a structured authoring approach. The business case is compelling for larger writing organizations; they will be the first to adopt structured authoring. Over time, improvements in available tools will reduce the cost of implementing structured authoring and make it affordable for smaller organizations.
That’s the average cost in the US to translate content into another language according to Slator, a translation news and analytics site. That number is not speculative; they analyzed the costs per word from over 80 actual proposals gathered by the US General Services Administration (GSA). You can view the source proposals here.
The roles and responsibilities in an XML (and/or DITA) environment are a little different than in a traditional page layout environment. Figuring out where to move people is a key part of your implementation strategy.
What’s the first thing that comes to your mind when I say “XML and content”? If large technical documents and back-end databases pop into your mind, you’re in good company. But many content-heavy groups can benefit from adopting XML. Marketing is one of these groups.
In this webcast, Simon Bate leads viewers through the key steps in using XSL (extensible stylesheet language) to perform XML-to-XML conversions, a process that differs from more traditional XML-to-PDF and XML-to-HTML conversions.
To understand how XML changes technical communication, we need to step back and look at how the rise of information technology has changed the content development process. Through the 1970s, most technical communication work had separate writing, layout, and production phases. Authors wrote content, typically in longhand or on typewriters. Typesetters would then rekey the information to transfer it into the publishing system. The dedicated typesetting system would produce camera-ready copy, which was then mechanically reproduced on a printing press.
In a desktop publishing environment, authors could type information directly into a page layout program and set up the document design. This eliminated the inefficient process of re-entering information, and it often shifted the responsibility for document design to technical communicators.
Originally published in STC Intercom, February 2010
I spend a lot of time giving presentations on XML, structured authoring, and related technologies. The most common negative reaction, varied only in the level of hostility, is “Why are you stifling my creativity?”
Does XML really mean the Death of Creativity for technical communicators? And does creativity even belong in technical content?
The relatively low percentage of lone writers who have implemented XML is a logical result of the typical lone writer working environment. Given the current status of the authoring and publishing tools, any lone writer who implements XML will need to master fairly demanding tools and technologies.
Formatting Object (FO) processors (FOP, in particular) often fail with memory errors when processing very large documents for PDF output. Typically in XSL:FO, the body of a document is contained in a single fo:page-sequence element. When FO documents are converted to PDF output, the FO processor holds an entire fo:page-sequence in memory to perform pagination adjustments over the span of the sequence. Very large page counts can result in memory overflows or Java heap space errors.
Moving a desktop publishing–based workgroup into structured authoring requires authors to master new concepts, such as hierarchical content organization, information chunking with elements, and metadata labeling with attributes. In addition to these technical challenges, the implementation itself presents significant difficulties. This paper describes Scriptorium Publishing’s methodology for implementing structured authoring environments. This document is intended primarily as a roadmap for our clients, but it could be used as a starting point for any implementation.
XML is rapidly becoming part of the required knowledge for technical communicators. This article discusses the three most important reasons that you should consider XML: automation, baseline architecture, and consistency.
A common argument for XML-based workflows is that they automate production and localization tasks. With XML, localization can be reduced to a fraction of its original cost, but how exactly does that happen?
Sarah explores automization in localization and two technology standards used in multilingual workflows: The Extensible Stylesheet Language (XSL) and XML Localization Interchange File Format (XLIFF).
As the many-to-many communication between blogs, forums, and the like grow in volume, official product information will become just one of the many sources available to readers. Product owners who isolate their official information from the conversation run the risk of not being heard at all.
XML authoring can help to close the documentation gap between official and user-generated content, integrating the two and ensuring their voice is in the mix.
Originally published in STC Intercom, November 2007
XML can benefit a publishing workflow in many ways: improving content reuse, consistency, and potentially automating much of the process. That all sounds wonderful, but XML is not the logical answer for everyone.
Implementing a structured authoring solution requires a significant change from the familiar desktop publishing routine to new tools, technologies, and processes. Switching to XML is going to cost time and money. Depending on your needs, it may not be the most efficient solution.