Step One: Check to make sure that the .odt isn’t just an .sxw in disguise,
What’s the problem with Google Docs? - ODF Converter Team Blog
During this “real life” tests, we noticed that all the files created with the online application “Google Docs” were not converted successfully. This was strange enough for us to look in detail at what was wrong. And we found out that Google Docs was simply not able to export to ODF. Actually, the file menu says “Save as OpenOffice” and not “Save as OpenDocument”. The output file is an SXW file (the legacy format from previous versions of Star Office and OpenOffice.org)… with an ODT extension! I don’t know if by doing this way the guys from Google wanted to make people think that they had implemented the ODF format, but that was a nice try! ;-) I guess that they are working hard to achieve the compatibility, but in the mean time our converter won’t be able to open documents made with Google Docs - no need to complain, we have commited to handle OASIS OpenDocument format, not all the formats of the earth!
Step Two: See step one.
XSLT, SchmeXSLT — Just change the file extension and thats it — *POOF* — it’s transformed from one document format to the other!
Uhhhh… Sure. Why not.
Crap. This hurts ODF for no good reason.
@Steve,
I agree that its for no good reason, though I don't think this reflects bad on ODF in particular -- The ODF folks are doing a hell of a job creating a hell of a document format. I know several of the ODF working group members and I know for a fact that these guys are going out of their way to ensure that all the T's are crossed and i's dotted, and that the specification itself is built on top of solving real world problems that need solving.
That said, this doesn't exactly make the task of building and testing an OpenDocument OpenXML converter any easier, as if the folks developing this converter are spinning their cycles attempting to fix problems that don't exist (in regards to what appears to be a problem with their conversion process/code but turns out to be a problem with pseudo ODF docs in the wild) then its going to take that much longer to build the tool, which *DOES* hurt ODF from the standpoint of the time to market of this same tool.
To be fair, the post seems to suggest they spent ~1 day getting to the bottom of this, so its not exactly a major showstopper of any sort. Of course, it does mean they are going to need to build into their test suite a way of making a determination if the document in question is not only a valid ODF document (that part is simple enough via RNG and/or XML Schema), but whether its even an attempt at an ODF document or not, spending time tracking down the culprit who is behind producing the invalid content such that they can attempt to circumvent the problem altogether.
Of course if this were to become a more wide spread problem -- then yeah, this would most definitely hurt the efforts behind ODF, as if the overall user experience is poor, regardless of who's fault it is, it holds potential to keep folks from using the format due to this same bad experience.
Lets hope this doesn't happen!