As an independent consultant working mainly with small businesses I find that my clients are reluctant to commit to DITA for a number of reasons. As DITA authoring tools become more user-friendly and more readily available some of these barriers will begin to fade. But in general terms, the more DITA tools that become available, and the easier they become to use, the better for everyone.
Some folks here are taking a very strong look at DITA. I'm certainly one of them. But we also have a huge legacy of documents in Solbook format (Sun's subset of DocBook). There are tools for editing such documents, and tools for processing them. and there are many people who are comfortable with those tools. So DITA isn't going to replace the world, just yet. But DITA makes extensive reuse possible. It's a format with a serious future, because "reuse" is a very big deal. It lets you single-source your information content so have one place to make an edit. That sort of thing becomes important when you have multiple revisions of a product, and/or multiple variations. It becomes important when different tools and different products use the same information in different ways. It can drastically improve quality, ensure uniformity of presentation. Finally, structured formats like DITA and DocBook create the kind of consistently-tagged information that allows for useful automation.
DocBook and DITA both have their places. They're both excellent for single sourcing. DocBook is better for what I call monolithic single sourcing, while DITA is better suited for discrete single sourcing.
If you follow the latest trends or have been to a conference recently, you may find the idea of choosing an XML schema puzzling. Isn't the question really, 'How should I customize DITA to do what I want'? While there are many good reasons to choose DITA, it's not the only schema in town.
If you can put together an authoring-publishing workflow that is form-fit to DITA, then using DITA can be a good choice. For example, if you’re using Oxygen to publish to Oxygen’s webhelp output, or using easyDITA to push to MindTouch, or pushing content into Antidot’s Fluid Topics, or Mekon’s DITAweb, or Componize’s Alfreso integration, or some other defined DITA publishing solution, then I think DITA can be a good approach.
The DITA OpenToolkit (DITA OT) provides a way to produce multiple outputs, including Portable Document Format (PDF) files; however, the technology for creating PDF files is limited, and modifying the formatting is challenging. This paper explains the alternatives and trade-offs for each method and helps demystify the decision process.
DITA is an architecture for creating topic-oriented, information-typed content that can be reused and single-sourced in a variety of ways. It is also an architecture for creating new information types and describing new information domains based on existing types and domains. This allows groups to create very specific, targeted document type definitions using a process called specialization, while still sharing common output transforms and design rules developed for more general types and domains.
I went to the Content Management Strategies/DITA North America 2008 conference (put on by CIDM), which took place in Santa Clara last week. While I went to support our co-founder's speech on DocBook versus DITA, I also used this opportunity to catch up with software vendors and single-source users. Here's my top #10 take-away list.
The Darwin Information Typing Architecture (DITA) provides maps for assembling topics into deliverables. By specializing the map elements, you can define a formal information architecture for your deliverables. This architecture provides guidance to authors on how to organize topics and lets processes recognize your organizing principles, resulting in a consistent, clear experience for your users.
In technical writing, synonyms and variants should be used judiciously and often avoided altogether. The use of one term consistently to express a given concept is preferred so that communication is clear and so that translation costs are minimized. For this reason, when synonyms and variants do exist in popular usage, it is common practice in commercial environments to choose one of the terms as the “preferred term.” This indicator of preferred usage needs to be documented in glossaries. Due to the limitations of markup languages for creating glossaries, usually the so-called preferred term is identified simply by making it the headword in a glossary entry and providing a definition in this glossary entry.
DITA is applicable to many publishing applications, including traditional narrative documents that don't seem, at first look, like candidates for ditification.
How a multi-national, regulated medical device company planned its migration to a DITA CMS by identifying stakeholders and defining personas, establishing a high-level process and system requirements, developing a content model, and figuring out what to do with legacy documents.
I’m coming to the conclusion that there are specific types of content that suit a DITA environment, and that the converse is also true: DITA is not the best solution for every content type. (DITA is the Darwin Information Typing Architecture, an XML architecture for designing, writing, managing, and publishing information.)
Here, in no particular order, I cover a miscellany of DITA challenges – content re-use, maprefs, folder structures, ditamaps, topicsets, and authoring-publishing workflows.
I’m continuing with my series about DITA. In this post, I explain parent-child page links, content re-use when the content exists in different elements, a one-folder-for-all-files organization, and a better workaround to transferring relative links to Drupal.
The DITA Open Toolkit is an open source implementation of the OASIS DITA Technical Committee's specification for Darwin Information Typing Architecture (DITA) DTDs and schemas. The toolkit is a major upgrade from its predecessor, the developerWorks version known as "dita132." The toolkit uses open source solution of ANT, XSLT (currently 1.0) and Java to implement transformation functions from DITA content (maps and topics) into different deliverable formats.
The IBM Information Architecture Workbench is an Eclipse-based freeware that I find marvellously handy for organising my thoughts and then committing those thoughts to DITA files. With it, I can model my ditamaps, generate DITA stub files* for the ditamap nodes, and edit the DITA files. Plus, if I draw a line from File A to File B, it gets registered in the ditamap's relationship table. All pretty neat and clean. It shows me, visually, how my topics are arranged in my book (and lets me move around files with a drag-and-drop action). It also shows me orphan files - those nodes that I created but did not link anywhere. And, I can edit the DITA attributes very easily in the Properties view.
I am very comfortable with using Notepad to write in DITA. But there are times when I forget if a particular DITA tag can be used at a particular place. For example, I regularly forget if <prereq> should precede <context> or follow. At such times, an XML editor that also validates your tags as you type comes in handy. XMLmind XML Editor is one such tool and comes bundled with the DITA DTDs and schemas. Its personal edition is free to use for non-commercial purposes and is, thus, great if you want a WYSIWYG DITA editor for your learning and other personal stuff.
The abbreviation DITA stands for 'Darwin Information Typing Architecture', an information architecture based on XML. DITA is not a mere reinvention of the wheel: rather, it sets the standards for known structuring requirements. The most striking feature of this architecture is the clear orientation towards a technology for structuring, which has already proved its worth in online documentation.