The Darwin Information Typing Architecture (DITA) is an XML-based architecture for authoring, producing, and delivering technical information. DITA divides content into small, self-contained topics that can be reused in different deliverables. The extensibility of DITA permits organizations to define specific information structures and still use standard tools to work with them. DITA is often compared against DocBook, a similar XML schema.
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.
Here’s a reading list for DITA materials when you’re just getting started. I’ve been fielding some questions via email and IM about DITA lately, and pulled this blog post out of my drafts. I hope it’s helpful.
Translation of documentation has traditionally been a major expense in the globalization process, especially if translations are required for multiple languages. The Darwin Information Typing Architecture (DITA) is an XML-based architecture for creating topic-based and information-typed content. It provides a number of features that, in addition to supporting high-quality information delivery, allows for more efficient and reliable localization of information. This article provides both an introduction to DITA and a discussion of DITA features that enhance document globalization.
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.
DITA maps provide a mechanism for ordering topics and creating a topic hierarchy. Because DITA maps consist of lists of references to topics, you can reorganize the content in a deliverable simply by changing the order of the topic references. You can create different maps referencing the same source topics to create two deliverables to meet different users' needs.
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.
One of the ideas that appears on the DITA 1.3 project tracking website has to do with extending the existing table model so that outputted tables are more accessible for those using spoken-word browsers. Oddly enough, this proposal provides more than just a brief description as to how it is supposed to work, so I have pieced together a brief overview as to how I think it is supposed to work.
This review strongly recommends DITA 101 for its clear presentation of DITA basics, with practical examples and easy to understand language. Previously, authors and managers would need to have read the full technical specification to attempt to gather such information.
What are your thoughts on whether wikis could be used for end-user technical documentation? I'd imagine that a more structured wiki based on DITA content (which may have already been created for end-users) might work well for technical documentation. Have you seen any good examples? I'd love to see a well-done example.
Our goal is to bring people together — think social network organized around XML, DITA, content management and related topics. This blog serves as a hub for white papers and URL resources, contains a calendar of XML-related events and conferences, tracks industry trends, and keeps members up-to-date as to “what’s new” on the site.
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.
In an interview with Diane Wieland, Ann Rockley and Steve Manning of The Rockley Group discuss some new ideas related to XML and DITA conversion. They share their thoughts on dynamic personalized content delivery and component content management, which is the topic of an upcoming CMS Watch report that Rockley is co-authoring.
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.
Think DITA is just for procedural technical documents? Think again. A new OASIS DITA sub-committee has been announced whose purpose it is to explore using the popular technical documentation standard known as the Darwin Information Typing Architecture (DITA) outside technical documentation projects.
Can DITA be used as a Help authoring technology? Superficially, of course it can! The DITA Open Toolkit includes an HTML Help transformer, an Eclipse Help transformer, and an HTML transformer (which can also generate some sort of Table of Contents). So isn't it obvious then? DITA is perfect for Help authoring. Or is it? Looking a bit deeper, it's not so obvious. Can I include context-hooks in my content? Can I specify a popup link? Can I build a modular Help system? If I can't, then DITA is probably not suitable for Help.