A National Archive Moves to ODF
Andy Updegrove writes "The National Archives of Australia (NAA) has announced that it will move its digital archives program to OpenOffice 2.0, an open source implementation of ODF. Unlike Massachusetts or the City of Bristol (which announced it would convert to save on total cost of ownership), the NAA will deal almost exclusively with documents created elsewhere in multiple formats. As a result, it provides a "worst possible case" for testing the practicality of using ODF in a still largely non-ODF world. If successful, the NAA example would therefore demonstrate that the use of ODF is reasonable and feasible in more normal situations, where the percentage of documentation that is created and used internally is much larger."
Years ago when Novell switched over to Linux operating systems, one of their largest fears was the trouble integrating their documents in a Microsoft stardard based world. It turns out that Open Office was more than adequate concerning reading/writing various document standards.
I think the dutch national archive also switched to odf.
What I think they meant to convey is that this will be a worse case scenario they can use for testing the practicality of using ODF in a non-ODF world.
But I don't actually think so...
Whereas I think this will be great for ODF, as the NAA will have to produce heaps conversion software to convert many formats to ODF but because they are an archiving operation, they won't ever have to convert back. Instead, I imagine that the common document format for outgoing files from of the archive will most likely be PDF...
This scenario won't test the ability for ODF in collaborative work among entities, something that I would see as the worst case scenario needed to test the practicality of using this format.
Having said all of that - to hell with everyone else - I have been using non Microsoft formats (first Star Office formats and now ODF) for five years now and rarely come across a problem. Then again, I am a simple user so I wouldn't expect too much grief. From my experience advising other people I can see that the true hurdle is not the file format, rather the application. Word and Excel are automated from so much business and scientific software that people just expect the results of their query or analysis to be dumped directly into their spreadsheet or word processor. So until Quicken or MYOB support something other that MS software, or until alternative software is produced that does, business will largely use MS.
On the other hand I strongly recommend to people to use OOo at home and with the ever increaseing compatability that OOo has with MS formats, this is not a bad option.
All documents were made with a flavour of Word or another, from word for MacOS 6.0 to the latest (at the time) word XP for windows. As you'd have already guessed, the only word processor able to make sense of all the documents at once was Openoffice.org. Of course, I faced issues (bulleting appearing "funny", for instance), but as I was applying a style I created, that was not a problem as long as the text was there.
No single version of word in my possession was able to open all the documents, some documents even crashing word XP with thunder and lighting.
I wrote the original version of the National Archives software that does the conversion. The current version of the software is available here: http://sourceforge.net/projects/xena
If anybody wants to ask any questions here I'll try and answer.
Our use of the OpenDocument format will be quite important, but it's only one facet of what we do. The Xena software has been developed with a plugin architecture that lets us use various external helpers to 'normalise' or convert to open formats any data objects in our care. For each data object, we use Xena to create a base64 encoded copy so that we can embed some metadata with it, and separately for a conversion to an open format. Much of the data ends up as XML, while images for example are png or jpg. We're currently investigating open audio formats. Xena is also used to 'present' data objects that it normalises.
Until now, Xena has made use of OOo 1.1.x for the normalising of office documents into flat XML. Other development priorities have kept the move to OOo2 in the background. I must stress that we have not yet released Xena with OOo2 support, there is more testing to be done and we feel that the release must be accompanied by good user and developer documentation.
The 'current' binary of Xena available at sourceforge is waaaaay out of date and will shortly be replaced by a much sleeker and more intuitive version. For the curious, anonymous cvs is pretty up to date. If you have a java 1.5 sdk and apache ant, check out a pile of modules and go nuts. Anyone who wishes to become involved in the development effort is more than welcome.
For anyone else, keep an eye on the http//xena.sourceforge.net/ for the upcoming binary release.