Blog Archives

AODC day 1: An Update on DITA Features, Tools and Best Practices

This week I’m at AODC 2010: The Australasian Online Documentation and Content conference. We’re in Darwin, in the “top end” of Australia. Crocs and docs, what more can you ask for! This post is my summary of one of the sessions at the conference. The post is derived from my notes taken during the presentation. All the credit goes to Tony Self, the presenter. All the mistakes and omissions are my own.

After a busy, informative and fun-filled morning on Wednesday, we broke for lunch. Then Tony Self presented the first afternoon session, called “An Update on DITA Features, Tools, and Best Practices”.

Here’s a photo of Tony. I took it on Thursday morning when he was presenting another session. (I thought I’d better mention that, because he’s sure to notice that he’s wearing his Thursday shirt!)

AODC day 1: An Update on DITA

AODC day 1: An Update on DITA

Tony’s talk covered these topics:

  • An overview of DITA: authoring, content management, publishing tools and the DITA Open Toolkit.
  • A preview of the features in DITA 1.2.
  • The usefulness of specialisation and constraints.
  • DITA as used in various help-authoring tools (affectionately known as HATs).
  • Delivery options for content authored in DITA.

Introduction to DITA

Here are my key takeaways from this part of Tony’s session:

  • DITA is an OASIS standard for a form of XML.
  • DITA is a semantic markup language. There are no presentational elements. This enforces the separation of content from form.
  • When working with DITA, you use a suite of tools rather than a single tool. So for example, you may use an authoring tool for DITA, a separate publishing tool for DITA, another tool for reviewing content, and so on.

Some examples of authoring tools:

  • Arbortext
  • FrameMaker
  • XMetal
  • XXE (XMLmind XML Editor)
  • Serna
  • DITA Storm
  • oXygen

Interestingly, the DITA Open Toolkit is not on the list. The toolkit does not offer an authoring tool.

A hint: Because DITA is a standard, you can use the authoring tools interchangeably. The content is stored in exactly the same format.

Some CMSes are DITA aware:

  • Xdocs can use XMetal, XXE or oXygen
  • DITAworks
  • Ixiasoft DITA CMS
  • SDL Trisoft
  • Vasont
  • Siberlogic Sibersafe

Author-it is not on the list, because it can’t manage DITA content.

Other DITA tools:

  • XMetal Reviewer (an addon to XMetal)
  • Leximation DITA-FMx (a FrameMaker plugin)
  • Content Mapper for Information Mapping

Publishing or rendering tools:

  • MadCap Flare (Flare is not an authoring tool. You can import your DITA content into Flare and then output it into another format such as HTML.)
  • RoboHelp (As above, RoboHelp is not an authoring tool.)
  • Antenna House
  • XMLmind DITA Converter (ditac)
  • DITA Open Toolkit
  • WebWorks ePublisher
  • WinANT Echidna (Tony created this tool.)
  • Arbortext Publishing Engine

Pricing varies considerably. Some tools are free and opensource. Others are commercial and quite expensive.

DITA working with help authoring tools

These are some of the points Tony covered around DITA and HATs:

  • None of the common authoring tools are DITA editors.
  • Some are good DITA publishing tools (in particular, Tony mentioned Flare an RoboHelp).
  • WebWorks ePublisher supports DITA content.
  • Author-it allows you to export your content into DITA format. Note that it exports generic DITA content, not the full semantic markup.
  • With RoboHelp 8, you can import DITA content.
  • Flare 5 supports the import and export of DITA content. It does not support a round trip.

Delivering DITA content

DITA Open Toolkit can convert DITA to:

  • HTML Help (CHM files)
  • Eclipse Help — Tony gave us a quick demo of an Eclipse Help help system. He was running an Eclipse standalone web server from his own machine.

Commercial tools can convert DITA to WebHelp, AIR Help, ePub (eBook format) and many others.

There also plugins for the DITA Open Toolkit, dubbed OT plugins, that can produce:

  • Simple WebHelp
  • Context-sensitive help (Eclipse Help and CHM i.e. HTML Help)
  • AIR Help
  • eBook content

Increasing demand for different help formats

Tony pointed out that more and more user assistance is being delivered on “unusual” media such as phones, tablets, GPS displays, eBooks and augmented reality goggles. One of the beauties of DITA is that the separation of content from representation makes it easier to support a multitude of output media.

Tony’s verdict: Is DITA ready for us to produce professional online help?

If you’re looking for tri-pane help output such as HTML, HTML Help and Eclipse Help, you can do that with the OT.

If you want professional-looking output, you can do that with some work on the CSS style sheets

If you need context sensitivity, you can do that too with a bit of extra work.

But DITA is not quite ready for more sophisticated features such as popups and dropdowns.

DITA 1.2

In this part of the talk, Tony went into the new features of DITA 1.2. I didn’t take detailed notes here. Tony has a lot of information and I’m sure he’d be delighted to pass it on.

One of the bits I found interesting was that there’s been some criticism of DITA 1.2. Some people say DITA is becoming more and more flexible (“sloppy”) and therefore less and less useful, in that you can now add new types of <div> to the DITA “task” topic type. When you upgrade to DITA 1.2, your task topics will automatically become “sloppy”. If you like, you can “constrain” them to make them more strict.

Also pretty cool in DITA 1.2: The new “subjectScheme” ditamap element supports facets, a concept discussed in Matthew Ellison’s earlier session on search. (I’ve blogged about Matthew’s session.)

The DITA 1.2 standard has not yet been officially released. Even so, some tools support it already:

  • Open Toolkit 1.5
  • oXygen

Choosing a tool

Tony gave us some points to consider when choosing a DITA authoring tool:

  • The tool should be as compliant as possible i.e. it should support the current DITA standard.
  • The tool should support the round trip, so that you can open DITA content, work on it and then save it as DITA.
  • You need a tool that supports specialisation, so that you can add your own topic types.
  • It’s good to have a tool that is as open as possible, so that it is extensible and interoperable.

My conclusion

Thank you Tony for a useful update on the current state of affairs in DITA world. In particular, Tony has given us some great information on the tools available. For me, as someone who does not use DITA but is interested in the technology and its aims, it’s really useful to get a quick blast of information in this way.


AODC – DITA workshop

This week I’m attending the Australasian Online Documentation and Content Conference (AODC) on the Gold Coast in Queensland, Australia. This morning Tony Self hosted a workshop entitled “Introduction to DITA”. I learned a lot, about the DITA schema itself and especially about its application and the team and management structures you might need if you’re planning a large documentation project using structured authoring.

Tony is a founding partner of HyperWrite. He has a wide experience in technical documentation projects and is a skilled and engaging presenter.

A point of interest: Much of the HyperWrite web site is maintained in DITA and is transformed to XHTML when rendering the web page.

This was an excellent session, and there’s far too much content to cover in a blog post. Here are some highlights from Tony’s lecture and the discussions within the class.

Introductory points

These are items Tony discussed before we dived into DITA itself.

  • A stated aim of XML is that all human knowledge should be stored in XML. Wow, I hadn’t heard that before. That beats the theory of everything!
  • We compared DITA with DocBook. DocBook was developed by O’Reilly as a means of making their publishing process more efficient. It’s now an open standard maintained by OASIS. DITA was originated by IBM, but is now also maintained by OASIS.
  • DITA is topic-based. A book, or other publication, is a “collection” of topics. DITA is usually thought to be better for procedures, help systems, and other types of documentation with can be broken down into chunks.
  • DocBook is document-based — you might write an entire book in one single file. It’s generally thought to be better for books etc.

Structured authoring

Structured authoring is a whole new way of writing. It requires new procedures, new team structures and new ways of thinking about content. The advantages you gain are things like:

  • Content re-usability (one chunk of information can be pulled into multiple different documents)
  • Single sourcing (documentation stored in one place and format; can be published to multiple formats)
  • Separation of content from presentation

DITA is designed specifically for structured authoring.

A question arose: How can writers make sure that the content they write will fit into the context in which it is used? Tony agreed that this is a concern, and one that is often discussed. In practice, the writer will often be given some context. He says that this concern is probably not as much of a problem as it appears up front.

This discussion brought to mind a web site I saw a few weeks ago, which allows DITA authors to load their documents (i.e. topic collections) onto a platform where others can review the output in its final form. The web site is supplied as a SAAS application. I can’t remember the site URL, and Googling it hasn’t helped. Does anyone know of this site?

DITA itself

Now we dived into the details of content re-use; repurposing via transformations; inclusion/exclusion of conditional text and the creation of a content model.

A question arose: Talking about the content model and the DITA schema, what do you do if the DITA schema does not contain the elements you need for your particular application? In this case, the example was taken from the RADAR equipment industry. Interestingly enough, a committee is currently sitting to design a new content model for the machine industry, which may contain the sort of “warning” elements required by the questioner.

In the wider context, DITA architecture is designed to encourage “specialisation”. You create your own elements to suit your needs. When you need to share your content model with others, DITA supports a process called “generalisation” to make this possible too. The core concepts of “evolution”, “specialisation” and “generalisation” are implicit in the name “Darwin Information Typing Architecture” or DITA.

We did some work on the basic elements of the DITA schema. A point of interest: One of the attendees noticed that many of the DITA elements are similar to the Dublin Core. Tony said that this is by design, for easy interchange.

The big debate around stem sentences 😉

DITA does not allow stem sentences! (Oh dear, the things that technical writers worry about.)

A stem sentence is the short introduction that you might put at the top of a bulleted list, for example. Like this:

To wash the dishes:

  1. Put the plug in the plug hole.
  2. Turn on the tap.
  3. …etc…

In DITA, there’s no legitimate way to add the above phrase “To wash the dishes”. This has led to fiery debate in the documentation community. No doubt it will continue to do so. You could cheat and add the phrase into a <p> element within the <context> element that DITA does allow before the <steps> in a <task>. But this has problems:

  • The stem sentence will not be included in the list of <steps>, if you use the <steps> as a unit outside the <task>.
  • The stem sentence will be an ugly orphan at the end of <context> if you use <context> as a unit outside the <task>.
  • The stem sentence probably duplicates the <title> anyway.

Oh dear oh dear.

So what do you think — are stem sentences a Good Thing or a Bad Thing?

The future

Tony asked what reading formats we might be using in 2010, for example. He mentioned Sony’s BBeB (BroadBand electronic Books). Now all we need is a transformation from DITA to BBeB.

A fun simulation

Try this out:

First, do the “Interactive Puzzle” in Part 1. Follow the instructions in the left-hand panel. You will remove all formatting from a web page, bit by bit. Now you can see how difficult the information is to assimilate when the presentation layer has been removed and there’s no semantic tagging. Then Part 2 lets you practise some structured authoring.

A DITA project team

These are the people who might be involved in a large DITA documentation project: the schema designer (if you need to add specialisations to the standard DITA schema); the information architect (creates the ditamap i.e. the structure of the documentation); information developers (these are the content authors); a publisher (defines the data transformation).

Tony pointed out that this specialisation of roles will actually take us back a few years, to before the desk-top publishing era. With DTP, most technical writers create the content, presentation, graphics, and so on. With structured authoring, the information developers are concerned only with the content.

The complexity in designing a topic-based documentation system

If your documentation base is very large, it’s a time-consuming and complex task to design and allocate the topics. Each topic may be re-used in multiple documents, and the topics are written by multiple authors. This needs very careful coordination and management.


Tony mentioned a number of tools for DITA and other structured authoring, including these:

  • XMetaL — authoring environment; an example of a DITA editing tool; includes a map editor (used to build your structure i.e. table of contents)
  • Task Modeler from IBM — for design of the maps
  • WebWorks — for defining the structure and publishing the DITA topics
  • Antenna House — converts ditamaps into PDF
  • Author-it — structured authoring; single sourcing; a mature product. But note that its DITA support is output only — you can output DITA but you can’t edit it within AuthorIT.

Tony has also developed his own publishing tool, using the DITA Open Toolkit. This tool handles the publication side of things, not the authoring or structuring. He is interested in any feedback you may have.

My conclusions

Thank you Tony for a very interesting session. I can certainly see the benefits of DITA as a storage format. The one thing I haven’t yet come across is that killer WYSIWYG editing front-end. With any luck, I might hear more about that in the next few days at the conference.

%d bloggers like this: