XML Authoring and DITA: An Interesting Analogy

Very often I come across the question – Why DITA? Here is an interesting analogy to try and answer the same. The purpose is not to define DITA, but to share my perspective on what DITA may imply for the technical authoring community.

In the XML authoring paradigm, the document is split into structure, content and style, which are analogues to Driving Rules (structure), car (content) and road network (style). If the content and the style are as per same structure (DTD/Schema), you can generate the output by combining content with the style-sheet.  However, it would not be possible to generate proper output using content and style sheets based on different structures. Similarly, if the cars and the road networks are designed as per same driving rules everything runs smoothly. However, if they are designed as per different driving rules, there would be chaos. E.g. it is difficult to drive a car designed for the US (right hand drive) in UK, where the road networks are designed as per left hand drive.

In a hypothetical world, where each country has its unique set of driving rules, the design of cars and road networks are unique to each country. It is difficult to drive a car designed for country X in country Y. XML authoring leads to a similar situation. Each organization and team has its own set of driving rules (Structure – DTD/Schema), hence it is difficult to share content or apply the same style sheet to content aggregated from different sources.

Imagine if all countries followed the same driving rules. All cars can be driven in any country, and the road networks could be designed, as per the driving rules, without any knowledge of the actual cars that would drive on it. DITA is similar to these universal driving rules. If everyone follows the DITA specifications, it would be easy to share content and apply the same style sheets to the aggregated content.

There have been other standards (universal driving rules) that have come up in the past. But they were good for specific kind of documents (terrains). DITA is different, as it is based on the premises that the same set of driving rules cannot be applied to all terrains (desert, mountains, city, etc.). Therefore, DITA allows each country to specialize the driving rules for its own unique requirements. In addition, DITA also has recommendations on the content (car) design – i.e. topics. This further makes it easier to reuse, manage and share content.

This is what makes DITA promising and makes it worth a serious consideration.




Posts from multiple members of the Adobe TechComm team.

4 thoughts to “XML Authoring and DITA: An Interesting Analogy”

  1. Hi Max,While I agree that DITA is a well-crafted, well-engineered doctype, there have been many other equally well-conceived doctypes that never went anywhere. Like the PC before it, IBM is doing a good job getting an open technology into the mainstream.Ultimately, however, DITA is likely as not to founder on the vast shoals of the non-technical tech writers among us. I’ve written about this problem (actually, it’s a problem with XML in general) on my blog that’s linked to my name here. As our hosts have asked us not to post URLs in the comments, just click my name and find “XML Heresy the First” if you’re interested.

  2. Hi Larry,> everyone was saying much> the same thing about> DocBook — that it was> meant to be customized> for specific needsYes, but DITA specialization is, at least theoretically, a much better form of customization. The class attribute lets processing tools manage specialized content without knowing anything about the specialization.At least some authors at IBM have been happy with their DITA specializations, Adobe looks to have a great DITA specialization for API documentation, we’ll have to see how it takes off in other companies.Topic-based authoring sure predates DITA, but DITA seems to have been built by people very focused on the publishing demands of that approach. Re-use and conditional publishing of content is handled elegantly by DITA.It is too early to tell with certainty, but my impression is that DITA will represent the first major advance in structured authoring since XML.

  3. Hi Aseem,from my point of view I would use your analogy a level deeper. That is, XML is the common rule-set and every customized DTD/Schema (including DITA) is a specialization.The XML/structure users are usually companies with a certain business model. Some companies need trucks to carry stuff over long distances, others are better suited with smaller cars which make it easier to stop at many locations. Also, every company in the first place tries to find ways to get their own business forward and they don’t worry much about sharing content outside their system.DITA and other standards seem to make the implementation of processes easier. But every implementation I have seen was very much specialized and moved more or less away from the original idea.My position: We have a standard (universal driving rules), which is XML, and every company is free inside this standard to select a DTD/Schema that supports their business model. In case they want to share their content, there is another standard, XSL, to transform this content into a form suitable for sharing.This is not against DITA, I just wanted to make clear that I don’t think DITA is the new DocBook (or other DTD). Even if would be working for a heavily regulated industry with a content exchange standard, I am pretty sure I would be using a private specialization for internal use (with internal meta-data) and transform documents for external use (and removing internal data during this process).My bottom line: Adding XSL support to FrameMaker was a great idea! Now we want more:* XSLT 2.0 (or a method to call external transformers in case Xalan is not enough)* At least: Being able to create a DTD reference from an XSL parameter (currently it must be hard-coded in the stylesheet)Regarding the structured application:* When opening XML: Controlling which template document is used based on XML attributes (language dependent templates)* When saving XML: Controlling XSL parameters from the source document (and not hard-code them in the structapps.fm)More ideas to come…Thanks,- Michael

  4. I don’t know. A few years ago, everyone was saying much the same thing about DocBook — that it was meant to be customized for specific needs — and it has been around longer than XML.In my opinion, DITA is getting a lot of attention because it’s trendy (using words like “specialize” instead of the correct but boring “customize”) and because topic-based writing is making a comeback. Yes, a comeback… Google for “Bell System Practices” some time. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *