This post is another in a short series of explorations of alternative ways to create and/or edit DITA content.
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!