»
DITA as an Information Exchange Model
Professionals that create, update and manage information have historically faced challenges with interchanging it with other organizations. The challenges have been overcome, to some degree, originally with SGML and more recently with XML. This interchange has been moderately successful in government-regulated industries (i.e. aerospace and military) or manufacturers (i.e. automotive and semiconductor) where adoption of a common data model (DTD) was driven by a strong business requirement. However, interchange historically has come with a price of how do you maintain structure and information interchange over time by all organizations involved?
The challenge of information interchange is made complex by the balancing act of the need to customize DTDs vs. stay with the industry standard. You need to meet the needs of your organization, however, if a DTD is customized too much, you lose a link to the very standard designed for your industry. If you do not customize enough, authors have to deal with XML tags and attributes that do not have context for their application. Too much customization, transformation scripts become more complex. On top of this, structure and hierarchy is mixed within the information, making it more difficult to maintain transformations between information types.
DITA is an emerging standard that provides an outstanding platform to promote information interchange, in an orderly fashion, within an enterprise or with other organizations. Today much of the focus of DITA is for groups to adopt it for authoring and publishing structured information. Think of the benefits as other groups in you company or even your suppliers and customers adopt DITA – you can provide product documentation as DITA information, and they can even provide you with DITA information. This success has been documented within IBM as more groups adopt DITA. This adoption should become wider spread to ensure the success and longevity of DITA as an information model.
The success of this universal interchange model is greatly assisted by developers taking advantage of inheritance principles designed into DITA. By focusing DITA specializations at lower levels of the topic hierarchy, interchange can be easily accommodated with minimal transformation scripts. Imagine the possibilities of interchanging topics with groups, suppliers and customers, in several different languages, and rapidly shipping products to meet new product marketing configuration requirements!
DITA provides several good methodologies for managing an “information supply chain” where supplier and consumer can easily interchange topics. DITA provides an excellent infrastructure for managing information at a topic level, getting away from document hierarchies that in the past have added complexities to interchange.
Several DITA sub-committees are forming to share ideas and specializations though an open interchange. What will be of interest is how widely adopted vertical industry specialization are implemented to meet their specific business needs and to ease information interchange. It will be important to make this as transparent for authors and publishers to gain wide acceptance. Next, we have to make sure is that DITA authors adopt minimization approaches to their writing styles, but that is a different topic for a future discussion.
I realize a “standard” interchange approach has risk on assuming that DITA specializations will remain at a reasonable level. Also, I do not wish to oversimplify the complex authoring and publishing processes in place for several years. However, the adoption of a new standard like DITA provides an organization to think out-of-the-box on the potential and possibilities with a new approach.
Other complexities – what happens if you and your supplier are updating the same topics and you need to accept updates? How do you manage conflict resolution at a topic level? Do you need to manage change bars? How do you manage topic lifecycle management where information becomes obsolete and must be retired? Add or remove suppliers? What topic maps reference that those topics? How do you manage to complexities of the historic changes over time? This will be the topic of discussion for my next blog and why a content management system is a requirement to automate these tasks and others not yet anticipated.
