Creating DITA topics using email

This post is another in a short series of explorations of alternative ways to create and/or edit DITA content.

Don Daymigration, editing
To: e-dita <>Subject: Creating DITA topics using emailDate: 7 April 2011As you begin to sip your "half double decaffeinatedhalf-caf with a twist of lemon" at your favorite coffee/internet bar, you suddenly get a brilliant blog idea that you want to jot onto a paper napkin, but your pen is out in the car. But one click away on your laptop is your email application. You open it, start a new mail, address it to your dedicated e-dita address, type in your subject line, and start drafting your idea into the body of the note. Press Send, and within moments your brilliant idea shows up posted as an editable DITA topic back at the server.

Posterous, Drupal, WordPress, Blogger, and other popular blogging services support the "uploading" and posting of content via email. The idea as pertains to DITA is straightforward: as a dedicated email server receives a valid inbox event, it pipes the content in standard eml format to a special parser that sorts out the significant metadata and message structure and puts it into an equivalent XML format (something like this process). The resulting document model is then transformed by XSLT into a DITA topic, and necessary routing events are generated on the server to mimic your actions to import and publish the topic just as if it had been created by someone working directly through the blog application.

Obviously the quality and richness of the conversion into DITA content will be limited by the capabilities of the email client in which you compose your email, but at a minimum you should be able to end up with paragraphs and lists. Rich text capability in an email composer might support representing most of the basic DITA structures including highlight domain elements. This is entirely good enough for basic publishing using any available DITA tooling. More semantics can be added later through reviews and content analytics.

In any event, this process is fully able to be implemented--it is just a Simple Matter Of Programming, as always.

Why pose these thought exercises? It is because of a question I asked several weeks ago, "What isn't DITA?" The general nature of the DITA architecture means that the XML format and tools can be used for scenarios well outside of typical product documentation.

For example, in disaster planning, it is wise to have multiple options for making mission-critical information updates to the information systems that support urgent response activities. In a scenario we've seen recently in world news, if you were an early responder for an accident at a nuclear facility, an email option could enable drafting new procedures right from the front line and sending them back to the crisis center, where the updates can be reintegrated into the Field Manual for use by response teams. Having multiple options for information updates during time-critical situations is part of a robust communications risk mitigation strategy.

Note: Doug Morrison and I will be co-presenting at Congility 2011 on May 26 on "Content Architecture for Rapid Knowledge Reuse," in which we'll describe how DITA can be designed as part of a workflow for agile knowledge capture and rapid publishing, utilizing common tools such as email and other collaboration techniques for getting urgent information into a controlled distribution channel. Doug and I each can offer a Speaker Network code for you to use at registration--read more about it on the sidebar on this page and at dita4all. This code will entitle you to a discount upon registration. We hope to see you there!