Getting your DITA content into a high-design format like InDesign is a tricky prospect. The biggest stumbling block is the fact that there is no intrinsic link between your ICML and the template that you flow it into. In the end, your InDesign template (you’re using one, right?) is the most important part of a DITA to ICML workflow; it contains the actual styles that will control how your output appears.
We’ve written before on what lurks beneath the surface of an InDesign file, and how drastically it differs from the DITA standard. When you’re looking at going from DITA to InDesign, though, there’s a lot that you need to take into consideration before you jump in.
For LavaCon Dublin, Sarah O’Keefe and I delivered a case study presentation on some of the roadblocks we have encountered in implementing DITA at ADP. This article summarizes the key points of the presentation. The presentation and this blog do not represent the views of ADP, LLC.
Your project is coming along nicely. You have your workflow ready, your style guides are composed, and things are looking up. However, you have complex metadata needs that are starting to cause problems. You need a way to ensure that authors are only using valid attribute values, and that your publication pipeline isn’t going to suffer. This is a situation that calls for a subjectScheme.
You have DITA. Now what?
More companies are asking this question as DITA adoption increases. For many of our customers, the first wave of DITA means deciding whether it’s a good fit for their content. The companies that choose to implement DITA find that it increases the overall efficiency of content production with better reuse, automated formatting, and so on.
One of the greatest benefits of using DITA is specialization. However, specialized DITA is more challenging and expensive to implement than standard, out-of-the-box DITA, which is something you should consider before you take the plunge.
When you’re coming up with a metadata strategy for your content, you should start by developing a taxonomy, or a hierarchy used to organize metadata. A taxonomy will help shape your metadata strategy and make implementation of that strategy possible. In this follow-up post to Making metadata in DITA work for you, you’ll learn some tips for creating a taxonomy that will succeed in helping your audience—both internal and external—find what they need.
In testing one day, I was running a set of sample content through the DITA-OT, and much to my consternation, the build was succeeding, but generating no content. The error log helped to ferret out the source of the problem; the preprocessor was attempting to extract a linktext and navtitle from an image file that could not be found.
The image in question was a keyref pulled in from a map referenced in the main map file. Everything validated, previews showed the images resolving correctly, yet the images steadfastly refused to be pulled in during preprocessing—so what was wrong?
Metadata is one of the most important factors in making the most of your DITA XML-based content environment. Whether you’re converting legacy content into DITA or creating new structured content, it’s important to know what metadata (or data about data) your files will keep track of and why. Coming up with a plan for using metadata can be tricky, so here are some tips to make the process easier.
This post provides an overview of techniques you can use to handle conditional content in DITA. The need for complex conditions is a common reason organizations choose DITA as their content model. As conditional requirements get more complex, the basic Show/Hide functionality offered in many desktop publishing tools is no longer sufficient.
Conditional processing is especially interesting–or maybe problematic—when you combine it with reuse requirements. You identify a piece of content that could be reused except for one small bit that needs to be different in the two reuse scenarios.
A DITA implementation isn’t merely a matter of picking tools. Several factors, including wrangling the different groups affected by an implementation, are critical to successfully managing DITA projects.
Note: This post assumes you have already done a content strategy analysis, which determined the DITA standard supports your company’s business goals.
In this webcast recording, Sarah O’Keefe discusses content strategy and the role of DITA in content strategy.
What DITA elements are available for syntax diagrams? And how does one go about using them?
In this webcast recording, guests Alyssa Fox (NetIQ) and Toni Mantych (ADP) discuss their differing DITA implementation decisions.
In this webcast recording, Sarah O’Keefe gives an overview of DITA, one of the major structured authoring standards in tech comm. You’ll also learn about DITA concepts, the business case for DITA, and typical scenarios where DITA is used.
The problem: DITA does not provide a default mechanism for encoding context-sensitive help information. This article discusses a new approach that avoids specialization and provides a maintainable approach for context-sensitive help mapping.
In this webcast recording, George Bina shows you how to create DITA content from zero to a full deliverable using oXygen. The full deliverable leads to multiple publishing formats.
Paul Wlodarczyk shows how cloud-based tools like easyDITA can change the way you approach collaboration, and in turn speed your time to publish and simplify your work process.
Need some basic metrics on your DITA files? Wondering whether your topics are the right length or not? Check out this new feature in oXygen version 13.
Modifying FrameMaker cross-reference formats: it’s basic and one of the cool things about FrameMaker. But not if you’re editing DITA files using FrameMaker 9 or 10.
Rendering vector images (such as line art or charts) for PDF output through the DITA Open Toolkit can be tricky. You would think that an exported GIF of a vector image would display beautifully in the PDF—but you would be wrong.
I have struggled to understand the keyref and conkeyref features added in DITA 1.2.
It wasn’t until we started applying them to our proposal workflow that I finally understood them. I hope this use case also helps others.
The Darwin Information Typing Architecture (DITA) provides an XML architecture for technical communication. Although implementing DITA is likely to be faster and easier than building your own XML architecture from the ground up, DITA is not suitable for everyone.
This article was originally published in STC Intercom in March of 2011.
A standards-based workflow is challenging. This article discusses the issues with DITA (an XML standard for technical communication content) and XSL-FO (Extensible Stylesheet Language Formatting Objects, a standard used to create PDF from XML (http://www.w3.org/standards/xml/publishing).
