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.
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.
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.
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 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.
In this podcast, Marlene Martineau of New Dawn Technologies explains why they adopted DITA, how they adopted it, the benefits they're experiencing, and the reasons why she'll never go back.
Want to get involved in the formation of one of the most important XML standards impacting content professionals? You can. And, you should. The folks at OASIS—the Organization for the Advancement of Structured Information Standards—have made it easy for just about anyone to participate.
DITA experts Don Day, Michael Priestley, and Gretchen Hargis address the topic architecture of DITA, tips and techniques, and general DITA questions.
DITA supports the proper construction of specialized DTDs from any higher-level DTD or schema. The base DTD is ditabase DTD, which contains an archetype topic structure and three additional peer topics that are typed specializations from the basic topic: concept, task, and reftopic. The principles of specialization and inheritance resemble the principle of variation in species proposed by Charles Darwin. So the name reminds us of the key extensibility mechanism inherent in the architecture.
It’s hard to go to a content management or publishing technology conference these days without there being a presentation on DITA — the Darwinian Information Typing Architecture. For the uninitiated, DITA is an XML architecture for authoring and publishing topic-based content, typically technical documentation. The brainchild of IBM, where it is used internally for many documentation projects, DITA is now an open-source standard under the aegis of OASIS.
This tutorial uses the DITA Open Toolkit 18.104.22.168 and the corresponding PDF plugin release, and Wrycan's demo text. This assumes you have a working DITA environment and can run the default formatting with PDF plugin.
While topic relationships can be stored in the topics themselves, as products evolve and user interfaces change, a topic that was required for release 1.0 of a product may no longer be needed in release 2.3. If related topics are maintained at the topic level, removing a topic that is no longer part of the system may involve modifying the related topics of a dozen different DITA files.