As may be rather evident, the above discussion barely scratches the surface of the ODT file format. However, with the knowledge I have hopefully imparted thus far, you should have little trouble "reverse engineering" the parts you need for yourself: Simply start with a blank document, add (only) the element you would like to understand, such as a table, and then save the document, unzip the ODT file, and open the content.xml file in an editor. Search through the file for a piece of text you inserted and then pick things apart. I assembled a thin folder of printouts relating to how an ODT file implements various aspects of a document; I have found the ODT file to be remarkably accessible.
Real-World Applications
At my workplace, the content material we manage, which turns into deliverable PDF files for customers, is stored in DITA XML topic files. (DITA stands for Darwin Information Typing Architecture.) This topic-based storage and management has served our in-house tech editors rather well, affording such things as content re-use, single-sourcing, and conditional content filtering. However, the content owners, those technical people closer to the product itself who own and author the raw content material, are not proficient with the DITA schemas—nor should they be.
To address the gap, we implemented an XSLT-driven process that converts the DITA material that was sent into the PDF files into a fresh "content.xml" file. This lone content.xml file is then zipped up into an otherwise blank ODT file and is made available for the content owners as part of the nightly build process. The content owners then are able to easily make edits to their content and, thanks to Writer's change-tracking feature, the tech editors can locate these changes, finesse the grammar and wording, and incorporate the changes back into the DITA XML files. I will admit right now that this particular XSLT was very complex to write—it involved step-debugging a highly recursive transform—and does not fully support the look and feel of the material as seen in the PDF file. But, for in-house editing purposes, this isn't strictly relevant: the content owners can review and approve the finalized appearance from the same PDF files that are delivered to customers.
Alternatively, you may have a process that you need to take in the other direction. Another use case involves creating a true "template" in Writer (an "ott" file) that can be given to a working group as a rather fancy fill-in form. The material in the resulting content.xml file can be scanned for (either by direct location, or by some applied style name, or via other mechanisms) and converted out to some other format. Consider the possibility of turning a "requirements" Writer document into a working skeleton for some test cases.
Closing Remarks
Hopefully, I have shown you just enough of OpenOffice.org's Writer file format to open up some possibilities for you to use it in new ways. By taking a blank document or document template, you can edit or replace the body section of the embedded content.xml file. By taking an existing document, you can find the content and transform it for other purposes. As the material inside the ODT file is readable text and reasonably well-structured XML, it is wide open to full, external, programmatic assault. Being able to take control of your own documents in this fashion is nothing short of powerful.
About the Author
Rob Lybarger works in a small IT shop in the greater Houston, TX area. Among other duties related to Ant and Java, he has written XSLT mentioned in the Real-World Applications section of this article and also performed various in-house customizations of the stock DITA processing and formatting stylesheets. At home, Rob enjoys spending time with his four month old daughter and being a highly satisfied owner of a Mac computer.
Add www.developer.com to your favorites Add www.developer.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.xReceive news via our XML/RSS feed
IE 7
Firefox 2.0
