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.
Besides Google Spreadsheets, EditGrid is another online spreadsheet support open document, with its charting function which Google Spreadsheets lacking as it taken taken the light apps approach, I invite you to give it a try.
Good to see that you are none the worse for wear, or Dublin weir, Rob, your presentation at the KDE event was very interesting. Regarding your 20 patterns it would be useful to know, from a lay viewpoint, what each of these would entail in terms of development
How is #8 (Validation of document) possible?
Also, a minor nitpick. Pretty much all of these are available with Microsoft software. But since ODF reuses free specs and is free, these are now available without vendor lock-in. :-)
#8 validation — an example might be accessibility proofing. So, today checking things like all images must have alt text is easy to do. But what if we want to verify that no chart relies on color alone to impart meaning? You might want to check this to ensure that the a chart is readable by the color-blind user. This is something that can easily be expressed as a schema constraint.
Another example would be a journal’s style guidelines with regards to figures, citation style, etc. It is not something you would want to mandate as the document schema per se, since each publisher is different. But it is something you might want to layer on as an additional set of pluggable constraints which can be evaluated when that particular output is targetted. My main point is validation is more than schema validation.
As to your second point, certainly these scenarios are possible with any well-written, platform and application neutral XML document format. That said, my reading of Microsoft’s OOXML does not leave me optimistic in that regard.
ODF as a set of patterns
I’m interested in developing and even in the utilization of software-related items 18, 19 and 20. Especially when trying relational searches. I see a way to make this possible would be the union of the existing standard formats. I highly recommend the utilization of MusicXML, besides the already used MathML. I wonder if anyone has more information on how to walk in that direction. Thank you very much!