Tuesday, March 28, 2006

DITA 2006 - morning sessions from Day 1

As I mentioned before, I thought day 1 of DITA 2006 was a little "marketing" heavy, meaning most of the sessions dealt with the benefits of DITA and not much technical detail.

Keynote: The Business Benefits Obtained from Using DITA at IBM – Dave Schell

Dave’s keynote was a good overview of the benefits of DITA. Key benefits are the same as other structured markup benefits: increased consistency of content, content reuse, multiple outputs from a single source, faster and cheaper globalization and enabling personalization. What I thought was interesting, were the numbers he shared. A typical infocenter at IBM contains about 5,000 topics! He said the content is maintained primarily in their source code control and tied to the software builds. I think if you are planning to author large amounts of topics in DITA, a content management system is essential.

DITA is Ready for Prime Time. Are you Ready for DITA? – Eliot Kimber

Eliot’s preso was one of the more interesting, and controversial of the conference. I enjoyed it immensely. Eliot commented, “The more interesting question is why would DITA not be the right answer?” Some of these reasons may include: a small writing group that cannot afford some of the tools that help to author DITA effectively, such as an author-friendly XML editor (Arbortext or XMetal) and a content management system (such as Documentum, Ixiasoft, or XyEnterprise).

The most controversial part of Eliot’s preso was the comment that

“In order to use DITA effectively, you have to Specialize!”

Derived types can inherit processing defined for their ancestors. Industries can also create a set of specific types for their needs. DITA Specializations, by design, reduce the risk of creating customizations (where with a DocBook customization you have to be careful about maintaining your customization when the standard changes).

Eliot also discussed some of the hidden traps you can run into with DITA:

  • Inefficient processes – automating an inefficient process will fail to deliver the expected benefits and cost savings!
  • organizational boundaries – must focus on the enterprise bigger picture if it’s to be done right.
  • technology limitations – no OOB DITA solution. info analysis still necessary to determine additional specs, format analysis and stylesheet dev, legacy data conversion, integration with other tools (translation memory, DAM, CMS, etc.)
  • resource utilization – SMEs perform time consuming formatting tasks, indexing content, redundant content creation, maintenance of reused content, using expensive resources for copyediting and production functions.

My other favorite quote from Eliot:

“Do not underestimate the level of expertise and effort involved to implement DITA smoothly.”

Tony DiSilva also started the recurring question at the conference:

“How do you know when you should be using DocBook and when you should be using DITA?”

Specialization is essential for larger companies. The decision for smaller enterprises may be fuzzier between DITA and DocBook. With DITA, you will likely need a CMS (increasing the cost). DITA 1.1 is focusing on adding features to enable books. (front and back matter, indexing, etc.). This will make it harder to decide between DITA and DocBook.

How can they play together? Perhaps DocBook could adopt some form of DITA specialization mechanisms for fallback processing of customizations. The two standards could/should align some of the core element types in DITA 2.0/DocBook 6.0. For example, DocBook predates HTML, so those tags weren’t adopted. DITA started with the HTML tags.

IMO, if you already have your content in DocBook, there is no compelling reason to switch or migrate your content to DITA. As Norm Walsh has pointed out previously, with possibly one exception, everything that you can do in DITA can be done with DocBook. We have helped several of our customers do DITA-like implementations using DocBook. If your content is unstructured, and you are moving to a structured markup standard, the decision is on more equal footing. Key considerations are: youth of DITA vs. maturity of DocBook, robustness of markup and toolsets, ease of exchange with other partners or groups (what standard are they using? how portable do you need your content? what is the expected lifespan of the content? what is the current structure of the content, and how much rework will be needed as part of the migration?).

My Discussions with the founding fathers of DITA

One of the great things about this conference is access to the founding fathers of DITA! I had a chance to chat with Michael Priestley, Don Day and Rob Anderson about several topics:

Is DITA planning to use/provide RelaxNG schemas?
Don Day – not really. RelaxNG doesn’t have default attributes, and DITA relies heavily on attributes.

Do you see any tie between DITAMaps and Topic Maps?
Michael Priestly – they are very different. DITA maps are much more hierarchical and constraining, where XTMs focus on relationships and are non-constraining.

Looks like this post is getting a little long, so I'll split up my posts. Stay tuned for more DITA 2006!


No comments: