Why DITA is cool
At a macro level, what are the primary means people use to assimilate information? We read text, we look at 2D or 3D images, we can look at animated data (e.g. Flash), or full motion video, and we listen to verbal instructions.
Some of these media types can be interactive (e.g. 3D images you can rotate or explode, Flash graphics that respond when you mouse-over, voice activated dialing, etc.), some, such as straightforward text, are passive. All of these are valid information vehicles, and frankly some are a lot better than others. If you could reach the same level of knowledge by looking at an image, or by reading 1000 words, which would you choose?
So there are three basic questions that need to be addressed here. First, how does rich media information get into a content management system? Second, what is the best way to manage complex, interactive, and integrated data types? Third, how is this information packaged and delivered?
So how does rich media information get to a location where it can be useful? Delivery of rich media information into a content repository is going to be driven to a great extent by the underlying enabling technologies that the applications vendor provides with its solution set. To begin, the information has to be well organized, from a contextual and a topical point of view. Most information creation applications support XML as a means of structuring content, so as a baseline reference, this is a good start. The problem with XML is that it’s so adaptable and useful, that it becomes widely used for nearly anything, so much so that the original intent (structure and context) becomes lost once it becomes widely deployed in a large enterprise. This conundrum is what lead to the rise of DITA (Darwin Information Typing Architecture), an XML standard originally developed by IBM for software documentation, and then (wisely) passed to a standards body (OASIS) for wider ratification and dissemination.
What is particularly convenient about DITA as a standard is that it specifically geared toward the requirements of product documentation. While XML is widely adopted as an information standard, it’s frame of reference is too broad for topic based content creation, which is where DITA shines. The really cool aspect of DITA is that it’s not specifically geared towards text as an information source, that just happened to be the first commercial user of the standard. DITA can just as easily be applied to a variety of information creation applications, including graphics, full-motion video, voice, etc.
So while most major authoring systems such as a FrameMaker, Word, ArborText, or XMetaL already support DITA as an authoring standard, a number of non-text creation applications are also looking at DITA as a standard for organizing information so they can also be found on a topic-based search. There are rumors that Adobe InDesign, Dreamweaver and Flash are moving toward DITA. Once that crossover occurs it means that as Rich Media information is created it can be tagged using a DITA to create a topic reference, so that when information is entered into a content repository is already primed to be found either by somebody searching for information on a specific topic, or by people who are browsing information structures such as an FAQ table.
A longer-term implication of this is that eventually consumers, field service technicians, educators, essentially anybody looking for information on complex technology will be able to access data repositories that include not only text, but also full motion video, graphics, voice walk-throughs, etc. All of this will be accessible as a search return to a topic-based query, which means if you go into a well-organized document database you’ll be able to get the exact results you need in a rich media format. Adobe is in an ideal position to exploit this market once they get past the point of thinking out like a desktop centric applications developer and begin thinking more along the lines of process flow and true information integration.
Details on how this information would subsequently be managed in the next blog