I recently gave a presentation where, in passing, I enumerated a variety of usage patterns for ODF, demonstrating that it had wide applicability beyond the traditional heavy-weight office-like editors. This diversion in the presentation was well-received then, so I offer you a fuller version of these points in blog form.
- Interactive creation in an a heavy-weight client application. This is the traditional mode of operation in KOffice, OpenOffice.org, etc.
- Interactive creation in a light-weight web-based application. We are starting to see this at Google with Writely and Google Spreadsheets.
- Collaborative (multi-author) editing. This includes the traditional “comment and merge” style of collaboration as well as real-time, multi-user editing, where multiple authors edit the same document at the same time.
- Automatic creation of document in response to a database query. This is the report generation model of use. Data source could be a web service rather than a database.
- Indexing/scanning of document for search engine.
- Scanning by anti-virus.
- Other types of scanning, perhaps for regulatory compliance, legal or forensic purposes.
- Validation of document, to specifications, house style guidelines, accessibility best practices, etc. So, beyond RELAX NG validation, beyond Schematron, into content validation that is beyond XML structure.
- Read-only display of document on machine without the full editor, for example a light weight viewer as a browser plugin or extension.
- Conversion of document from one editable format to another, i.e., convert ODF to OOXML.
- Conversion of document into a presentation format, such as PDF, PS, print or fax
- Rendering of a document via other modes such as sound or video (speech synthesis)
- Reduction/simplification of document to render on a sub-desktop device such as cell phone or PDA.
- Import of ODF into a non-office application, i.e., import of spreadsheet data into statistical analysis software.
- Export from a non-office application into ODF, such as an export of a spreadsheet from a personal finance application.
- An application which takes an existing document and outputs a modified version of that presentation, e.g., fills out a template, translates the language, etc. This has some nice benefits since it allows separation of concerns, where a business user can control the look of the document, but leave place holders that can be filled in by automation, perhaps based on a web service query.
- Adds or verify digital signatures on a document in order to control access (DRM)
- Software which uses documents as part of a workflow, but treats the document as a black box, or perhaps is aware of only basic metadata. This is the way most current systems work.
- Software which treats documents as part of a workflow, but is able to introspect the document and make decisions based on the content. This relies on the transparency of the ODF format, and the ability for software to see what is inside.
- Software which packs/unpacks a document into relational database form, i.e. XML-relational mapping.
I am interested in other patterns of use you might have, especially ones that do not overlap the above.
The exercise of producing the above list made it clear in my mind that many of these items should be given more consideration than they traditionally have. For every document created in a heavy or lightweight editor, there may be many other much smaller applications which will need to read the document down the road.
By analogy, this blog entry was created an editor, but the number of readers, indexers, aggregators, etc., that will touch it in downstream processing will far exceed, in number and processing cycles, the effort spent in writing it. So ease of processing, especially ease of reading, is an important consideration for designing and evaluating an XML document format.