Starting with the somewhat silly, OOXML does not conform to ISO 8601:2004 “Representation of Dates and Times.” Instead, OOXML section 3.17.4.1, “Date Representation,” on page 3305, requires that implementations replicate a Microsoft bug that dictates that 1900 is a leap year, which in fact it isn’t. Similarly, in order to comply with OOXML, your product would be required to use the WEEKDAY() spreadsheet function, and therefore assign incorrect dates to some days of the week, and also miscalculate the number of days between certain dates.
More substantively in the contradiction department, OOXML does not follow ISO 639 “Codes for the Representation of Names and Languages.” That standard defines a list of codes that are maintained by a Registration Authority charged with keeping the list current as ethno-linguistic changes evolve. Instead, section 2.18.52, “ST_LangCode (Two Digit Hexadecimal Language Code)” (page 2531) says that you must use a fixed list of numeric language codes rather than the already existing set that provide for interoperability among other standards-compliant products – a not unimportant factor in a text standard.
Updated 9-29-07: Peter Constable, the Project Editor of ISO 639-3, contacted me to say that the statement above is inaccurate, stating in part that OOXML, “happens also to allow for a set of integer identifiers defined by Microsoft, provided for backward compatibility with existing documents, but that does not contradict its usage of ISO 639,” and requesting that I correct the record. I then checked with my original source, who responded as follows:
I’d direct Mr. Constable to DIS 29500, Part 4, Section 2.16.5.35 (page 1540). The definition of the “/z” field argument says “The text in this switch’s field-argument is specifies the language ID used to generate the index as defined in the ST_LangCode (§2.18.52) simple type.” If he further references 2.18.52 he will see that ST_LangCode in no way uses ISO 639 language codes.
However, it should be noted that there are other sections in OOXML where ISO 639 codes are allowed, but as the above example demonstrates, there is at least one place where OOXML permits only the non-standard Microsoft codes, in contradiction of the existing ISO standard for language codes.It therefore appears that my statement was both right and wrong on this point, and that OOXML is both compliant in some sections, but not compliant in at least one section. End Update
Similarly, 6.2.3.17 “Embedded Object Alternate Image Requests Types (page 5679) and section 6.4.3.1 “Clipboard Format Types” (page 5738) refer back to Windows Metafiles or Enhanced Metafiles – each of which are proprietary formats that have hard-coded dependencies on the Windows operating system itself. OOXML should instead have referenced ISO/IEC 8632 “Computer Graphics Metafile” – a platform neutral standard.
Taking the external reference issue further, I’m told that parts of OOXML can’t be implemented by your typical programmer at all without technical assistance from Microsoft, as they refer not only to proprietary Microsoft products, but to undocumented parts of them as well – which violates the General Principles of ISO/IEC Directives, Part 2. Consider the following, from section 2.15.3.26 (page 2199):
2.15.3.26 footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement)
This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.x/95/97) when determining the placement of the contents of footnotes relative to the page on which the footnote reference occurs. This emulation typically involves some and/or all of the footnote being inappropriately placed on the page following the footnote reference.
[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]
Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.
[Example: Consider a WordprocessingML document with a series of footnotes.
If this compatibility setting is turned on:
Then applications should mimic the behavior of Microsoft Word 6.x/95/97 when determining the placement of those footnotes on the displayed page, as needed. end example]
Other parts of OOXML refer to OLE, macros/scripts, encryption and DRM – none of which are fully described. Nor has Microsoft stated whether necessary information will be supplied on a non-discriminatory basis to all (or at all).
And taking that concern a step further, consider the fact that OOXML also apparently violates section 2.14 of the ISO/IEC Directives, Part 1, in that not all of what it takes to implement OOXML appears to be covered by Microsoft’s patent pledge, in two respects.
First, the pledge does not explicitly cover material that is referenced, but not included in the specification, and second, the Microsoft patent commitment does not cover optional features. Sections of OOXML that are not fully described include those that require compliant implementations to mimic the behavior of Microsoft products, such as those products and capabilities referred to above (OLE, etc.) Microsoft will need to clarify whether its patent commitment will in fact extend to these requirements. Potentially, these concerns would involve large portions of OOXML, in contradiction of the ISO/IEC requirement that more than a bare-bones implementation must be permitted without fear of infringement.
All in all, as the waitress in the Monty Python vignette would doubtless have observed (if contradictions were rats), “Rather a lot, actually.”
As the February 5 deadline for report ing contradictions approaches, I expect that you’ll be hearing of many more examples such as these. Eventually, they will all become publicly available, along with the proposed resolutions. Some, such as the patent pledge ambiguities, are clearly addressable by Microsoft if it wishes to address them.
Other contradictions would seem to be impossible to resolve given the nature of OOXML itself, the stated purpose of which is to describe a single vendor’s product – bugs, rats and all.
Updated: Pamela Jones and her crew have set up two very impressive pages at Groklaw, in Wiki format. The first allows interested parties to find and log in contradictions and objections, while the second tracks the ISO/IEC process. Pamela’s own detailed writeup can be found here.
For further blog entries on ODF, click here
subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff’s)
A serious question: is there any practical point in finding and publicizing all of the bad things in OOXML? (and there are some things, such as those you mentioned in this post, that any real standards organization would never have allowed) What are you trying to accomplish?
Those that support OOXML do so for political reasons, not for technical reasons. Those that support ODF do so mostly for political reasons, not technical reasons. Thus, the technical merit of either spec is largely irrelevant,.
— Swashbuckler
Here’s a (hopefully) serious answer. It might even be right!
First, I take issue with your oversimplification that it’s all politics and no technology. Obviously there is political motivation involved on both sides, but there are more important things to be considered.
ODF is a format which was developed to be a truly open standard that anyone could implement. When Massachusetts decided to go with ODF, the logic was simple; they wanted someone 100 years from now to be able to create a program (or whatever it’ll be called then) from scratch that can open and display a document that had been archived. This is not a trivial issue.
Massive amounts of information (including census data, I believe) is literally rotting into oblivion. The old magnetic tapes are deteriorating, and no computer of any kind exists that can read those tapes, much less do anything with what’s on there. Governments, particularly, deal in decades and centuries, not quarters and years. ODF is an attempt to avoid the mistakes of the past going forward.
OOXML, by all accounts I have read (which is a lot), is an attempt by Microsoft to legitimize its own proprietary format as an alternative standard. I cannot see ANY way that this mess could be the basis of a long-term open standard by which someone 100 years from now could create a program from scratch to open OOXML documents. The information presented here (and in other places) demonstrates that the specification as submitted could not be used to create a working program from scratch on any platform (even Microsoft Windows!), today or 100 years from now. It is widely regarded (and I believe correctly) that the sole purpose of trying to get OOXML established as an ISO standard is for short-term (as in the next few years) marketing purposes by Microsoft.
I will further submit that if your argument has no more depth than what you have said, then you, sir or madam, are a troll. Hie thee back under thy bridge!!!!!!!
Weeble
I think the problem I have, and likely Microsoft as well, is that there are literally Millions of existing documents with varying kinds of formatting that need to be converted to any long term storage format for the idea to even hold any water. It doesn’t really help if only new documents can be accurately represented by the format. There are varying degrees of accuracy in conversion from legacy office format files to ODF, but in my experience, all but the most basic kinds of documents fail spectacularly in the process and need some kind of touch-up. It gets even worse when you need to represent the document as it was originally created for legal or artistic reasons.
What I think Microsoft needs to do is restructure OOXML to provide for legacy formatting, but leaving a core sane format. Some might argue that this format should be ODF, but I can already see everyone and their dog accusing Microsoft of “embrace, extend, extinguish” tactics if they did so. They could even be sued on anti-trust grounds for doing so.
The fact that there are already millions of documents that need to be represented by an open format alone is enough to justify an ISO standard for such documents.
You have to distinguish between a standard and an import filter for legacy formats.
As only Microsoft has the original code, they are the only ones that can convert all the legacy documents into any new format.
However, it is totally rediculous to include all (or even any of) these undocumented formats into this new format.
Legacy formats must be converted, not preserved.
<i>You have to distinguish between a standard and an import filter for legacy formats.</i>
Exactly.
All the crap about bugs in previous versions of the applications should have been corrected as a part of the import process, not propagated for all time.
— Swashbuckler
I would add that while a tool to convert legacy documents into a format for going forward is a good thing, since Microsoft is the only company who has the knowledge to do that (adequate knowledge is not in the spec), there’s no need for it to be an ISO standard. How can something be a useful standard if only one company has the knowledge (proprietary, no less) to implement it?
P.S. I would be more persuadable if Microsoft released a basic, free (as in beer and as in speech), open-source, cross-platform capable (standard languages, not requiring MS programming tools) editing program for manipulating OOXML files, capable of accurately importing any and all of the formats referenced in the OOXML specification, allowing manual and/or automatic correction of import errors, and capable of accurately exporting a “clean” OOXML file. Better yet, a “clean” OOXML or ODF file, demonstrating a true commitment to interoperability. The program’s source code would be appended to the ISO application as a working example of how to implement the proposed standard.
However, I cannot see that occurring under the present management of Microsoft.
The think you mentioned, millions of documents are there now in M$ way documents it is true. But it all make M$. It is their policy, and it is pretty bad
They made it bad and want you to pay for it every year.
If you have document in latex, pdf, … You can see it and work on it today, like 10, 20 years before. If you have something in M$ oficcee version 3.1415 you are in trouble.
When I was in university, I remember one mathematician, who said ouch, I have to have Word 2.0, 3.0, 4.0, 5.0, and some more minor releases, if I want to read papers from my colleagues.
In 100 years you have to have aproximately 60-70 releases of various M$ office packages, if you want to read documents. If you write doc in latex, pdf, odf(hopefully|, you’ll still need one software for reading it, as you do 100 years before.
I’m familiar with all of that, however that’s not the real reason that people support ODF.
It’s like the invasion of Iraq, the Bush administration claimed there were WMD, they wanted to free the Iraqi people, spread democracy, etc. But the real reason they went in is because they wanted to get rid of Saddam.
Same kind of thing here. Just because something has a benefit, doesn’t mean it’s a reason something was done.
— Swashbuckler
Swashbuckler, I readily grant you that there are those who support ODF partially, or even primarily as an extension of their dislike of Microsoft and would have no qualms about firing all of the senior management there or even dismantling the company if they had the power to do so. I have been a Microsoft watcher since the late ’80’s (not long after I got into PCs in the first place) and believe that if Microsoft were shut down today, the world of computing would be better off (except for the short-term mayhem).
And there are good reasons for taking that stance. From its earliest days, Microsoft (then Micro-soft) has built and maintained its business by cheating, stealing other people’s ideas (has Microsoft REALLY been innovative other than in creating “Microsoft Bob”?), using its market power in an extremely predatory manner (established as fact in U.S. v. Microsoft), undermining competitors with false claims of products that showed up far late if at all (i.e., vaporware) as well as with subtle half-truths and lies commonly known as FUD, protecting the slop it calls software via vendor lock-in, and the list goes on and on.
Some do promote ODF/open source/FOSS/Linux/etc. partly or primarily because they detest Microsoft. However, from what I’ve seen (and I’ve seen a lot), most do so out of altruism, desiring to better their world, and from a desire to “build a better mousetrap”. This is specifically so with ODF.
Please, sir, if Microsoft’s desire to promote their proprietary OOXML format by seeking ISO certification based on a half-baked document that enables no one but themselves to implement it (because only they can fill in the blanks) is based on altruism, desiring to better their world and/or a desire to build a better mousetrap, where is the evidence of this?
All I have seen in your posts so far are half-truths, innuendo and ad hominem arguments. I challenge you to provide some fact-based arguments that ODF is being promoted primarily because of a vendetta against Microsoft (as opposed to the altruistic motives mentioned above) or else admit you are a troll AND GET YOURSELF BACK UNDER YOUR BRIDGE!
Grow up.
Those who support ODF may do so for technical and/or political reasons…. but, in many cases, the political aspects of ODF support have to do with fighting for the technically better solution.
Whether your reasons for supporting ODF or OOXML are technical or political, there are a number of technical (and possibly also political) reasons for looking for the flaws in this proposed standard:
You’re going to get a far better listening if you say “It has these M minor problems, these N serious problems, and these K probably insurmountable and structural problems, and I think that these flaws are so serious that OOXML should be completely rejected.”
As many people have pointed out — despite being a massive 6000 page document, the OOXML proposed standard doesn’t actually have enough information for anybody (other than Microsoft) to implement it — and what’s value of a ‘standard’ that only one entity can implement?
I’m replying late to your questions (my apologies), and I think that those who have already replied have covered the ground pretty nicely. Here are a few more thoughts around the edges.
First, the fact that ODF can (and actually has) been implemented in many products means that its a lot more likely that documents will stay available over time – in part because more developers will have motivations to support it than OOXML. And many other good things will follow as well, such as choice, price and feature competition, and so on. None of that will happen with OOXML, which is more like a more open (but not completely open) toolkit for a single product than a standard.
On another point, there’s no question that the genesis, and much of the current support, for ODF was and is “political” in the commerical sense (if that’s what you meant) in that the core came from Sun, and the standard is being pushed as hard as possible by vendors (most notably IBM and Sun) for commercial advantage. But it’s also true that ODF has a large and growing following of open source developers and customers, which are not motivated by politics, or at least by the same type of politics.
In that sense, you could anlogize loosely to Linux, which points back to UNIX – a commercial product. Linux is, of course, beloved by open source developers and customers alike, while at the same time being pushed hard by commercial vendors for the traditional profit and competitive reasons.
– Andy
The politics I was referring to was being pro or anti Microsoft.
Some will support Microsoft in (nearly) anything they do because Microsoft did it and their fortunes depend upon Microsoft. Some will oppose Microsoft in literally anything they do because they dislike Microsoft for any variety of reasons.
Do you believe that any company or open source project is going to chose to support or not support OOXML based on the technical merits of OOXML? I don’t. If Microsoft hadn’t put all the stupid requirements to replicate bugs from previous versions of Office into OOXML would that have affected the decision of any company or project? I don’t think so. Thus, while the stupid stuff in OOXML is interesting, pointing it out seems to serve no practical purpose; it merely allows those that oppose OOXML to say “See, I told you!”
You can’t even use this to really slam ECMA, as it has long been known as a rubberstamp “standards” organization. I had some involvement in a couple of ECMA efforts ten years ago, and that was the case then and it’s still the case today.
— Swashbuckler
All the half (or less) documented garbage in the present OOXML standard is enough for it to shoot its own self in the foot.
OOXML is NOT a document format for going forward. Rather, it is a document format intended to reach back to the past and carry it along. That’s a recipe for disaster, not for a standard. Such a format could only become more and more bloated as it has to support more and more emulated characteristics.
Maybe I’m dumb, but an office package that costs as much as Microsoft Office does should, when importing a document, be able to translate the document into its own terms rather than simply emulate characteristics of the old format. And when the document is saved in the new format, all of the characteristics should be in terms of the new format. It has been a surprise to me to learn that the older MS Office formats didn’t do that. If they can’t or won’t do the work to translate a document’s characteristics into those of the new format, the default should have been to save it back in its existing format.
Even if I *wasn’t* of such a strong negative opinion about Microsoft, I’d still think this is a stupid way to run a railroad. Or a software company.
On the other hand, reading the contradictory statements is rather faster than reading the whole proposed standard. Having then published and or summarised elsewhere (than ISO) is good.
I, for one, do not have the time to read the standard, and do the research that will show me how much in deep trouble I could be if I moved my documents to OOXML. Note that it does not matter if I would actually consider doing it or not: it is obvious that this is a political fight, but even political fights can be won by public pressure (and, alas, note again that public pressure can win the “right” fight, or the wrong one).
ISO is, as any other organisation, a political beast, and will sometimes react to political rather than technical merits.
Wrong. OOXML is supported for commercial, not political, reasons, and
ODF is supported by anyone who wants interchangeable and lasting
documents, as it is technically good and the only standard.
right.
from Michael @ <a href=http://www.tinpok.com/>tinpok.com</a>: <a href=http://www.tinpok.com/>Hong Kong Web Category</a>
Microsoft’s description of these ‘blobs’ seems to imply that they expect the implementor to effectively reverse-engineer Word/97 and other ‘legacy’ versions of MS Works, MS Word and other MS Office products. It’s been a while since I read the EULAs for those products, but I’m betting that some (if not all) of them claim to prohibit such reverse engineering. In venues that claim to legitimize shrink-wrap licenses, this means that — even if Microsoft were to grant the necessary patent rights needed to implement those blobs, an implementor might find themself embroiled in a legal fight with Microsoft as to whether or not the information necessary to complete the information was gained legally.
In other words, if Microsoft doesn’t fill in the blanks for these proprietary and/or legacy blobs, an implementor might find, in addition to the technical problems, not one — but two — legal hurdles should they ever succeed at implementing OOXML.
OOXML seems a bit like EBCDIC (a single-vendor standard really intended for use with punch-cards), playing opposite ISO ODF XML being like ASCII (American Standard Code for …, a vendor-neutral standard really intended for use with paper tape).
It’s good that Microsoft have finally coughed up a description, it may well take 50 years to work its way out of the ‘system’, just as ASCII-based representations are slowly pushing EBCDIC-based representations out. Punch cards and paper tape are both long gone, but we still need some way of agreeing what the zeros and ones in our computers mean.
But there should be no need for ISO to bless a single-vendor standard.
<p>Andy,<p><br>Just how does one find out who is the ‘national standards body’ is for any given country and equally important, how to contact them?<p><br>Presumably for the US, the National Bureau of Standards {?} is the correct body. But then who to contact? Actually, I think they’re now the National Institute of Standards and Technology. {http://www.nist.gov}<p><br><br>
ISO member bodies are listed at http://www.iso.org/iso/en/aboutiso/isomembers/MemberList.MemberSummary?MEMBERCODE=10. The member body for the US is the American National Standards Institute (ANSI).
Vance
And in Singapore it is the National IT Standards Committee – http://www.itsc.org.sg.
Harish
h dot pillay at ieee dot org
http://www.bsi.org.uk
OpenDocumentFellowship has
a document that defines what a standards “contradiction” is. That’s
important, because specifications aren’t supposed to enter the fast track if
there’s a serious contradiction.
And this case, there are lots of
massive, fatal contradictions that should immediately derail the “fast
track” (and really, the whole specification). Let’s look at the possible
reasons for a contradiction:
confused by the “term ‘open'”; users might think it means that the specification
represents some sort of industry consensus, or a specification that is widely
implemented by many suppliers, or one with fully open IPR (e.g., so partial
implementations and later versions are unencumbered). This is not true. For
example, there doesn’t seem to be a legal way for others to fully implement it
(due copyright on material like graphics borders and EULAs forbidding reverse
engineering for inadequately specified pieces). This specification does not
meet many of the common definitions of the term “open standard”. Users may also
confuse the specification with OpenOffice.org, a product that implements
OpenDocument instead.
specification, ISO will be tarred as an organization that can be controlled by
any single powerful company, instead of one that strives for broad industry
consensus and protection of users’ interests. Look at the precedent this sets –
if ISO accepts this specification, it means that a rich company can overturn any
existing standard (e.g., OpenDocument) simply by buying off a standards
organization (ECMA) to accept whatever they write. ISO’s key value is in its
reputation for impartiality, and should not sully such a valuable reputation for
such an obvious ploy.
Obviously this isn’t consistent with ISO/IEC 26300 (OpenDocument). Which was
approved as an ISO standard in 2006, so it’s clearly not obsolete. What’s
worse, it’s completely inconsistent with other standards: MathML, SVG, XForms,
and so on.
OpenDocument. Completely. There’s no “different market” for office
documentation; it’s all the same market. Indeed, the fact that people are
working on bidirectional translators shows that they are the same thing.
There’s no need for yet another standard for the same thing, unless of course
you’re trying to ensure that a single vendor controls the format of all office
documents.
“overlap”. This is essentially a complete duplication of an existing standard,
for the sole purpose of enriching a single company (at the expense of
competition in the marketplace).
Another problem is that the
specification, for all its pages, doesn’t get to the meat of the specification.
You can’t really implement it without “secret sauce” information that only
Microsoft has. It’s a non-specification specification. It’s only so long
because they had to re-create incompatible specifications for functions that are
open standards elsewhere (like MathML and SVG).
This specification is also
grossly immature; even if were not a contradiction, it’s not ready. It can’t be
otherwise:
(!). In contrast, OpenDocument development began December 16, 2002 and was
approved May 1, 2005. And OpenDocument development was much easier, because
they reused standards (like SVG and MathML) wherever they could, instead of
recreating things from scratch.
were not involved in the ECMA process (for development OR review), for
good reasons. After all, nearly all office application suppliers had spent
years working to develop a standard; there was no need to do it again (note that
the ECMA process only started many months after OpenDocument had been
completed). The ECMA process, by charter, was clearly unfair and tilted
towards the whim of a single vendor. And technically, because the specification
completely redoes from scratch many standards areas (like MathML and SVG), there
are many good reasons to avoid implementing this
specification.
There’s no terrible harm to Microsoft if ISO rejects
fast track status, or even the spec outright. Microsoft can implement the
industry-developed international ISO standard (OpenDocument) any time it wants
to. If there are problems with the standard, they can be addressed through
normal standards processes. But allowing a single company to create its own
incompatible, essentially proprietary standard will do great harm to the
reputation of all standards bodies.
ISO says its goal is
“one standard, one test, and one
conformity assessment procedure accepted everywhere.” Do they mean it? Or is
that a lie, just another empty claim that can be sold to the highest bidder? Is
it possible for an industry to work together for many years to develop and
implement a standard, and then as the standard begins to be adopted, for a
single vendor to write its own incompatible specification and get ISO’s
endorsement?
We’ll see if ISO can really stand for its principles. I hope,
and have reason to believe, that ISO can, and reject the fast track request.
(I previously posted this on Groklaw.)
No undeserved harm, certainly, but terrible indeed if users found that they didn’t need to use Microsoft products to read all their documents.
thinking your point. I think you are right.
from Michael @ tinpok.com
The language codes on pp. 2531-2537 of the Open XML spec are said to consist of exactly two hexadecimal digits, yet they range from 1033 to 58380. These are not hexadecimal values and cannot be represented by two hex digits. Am I missing something, or has Microsoft screwed this up?
I should add that Microsoft does have two-digit hex codes for languages, e.g. 0x09 for English. What I don’t understand is why in the spec they refer to these hex codes but show the non-hex codes like 1033 instead.
This question inspired me to look at this a bit more and add it to the EOOXML Objections page on Grokdoc mentioned before.
Under the fast track process it appears that there is a 1 month (calendar month?) review period, followed by a 5 month voting period.
What does this mean in practice?
Do the NSBs vote once only? Or can they vote with objections and then alter the vote if they wish?
Do they vote at any time during the process or just at end beginning/end?
Are the NSBs very political or is it worth trying to influence them by making direct contact?
What sort of arguments are likely to be effective?
Thanks,
felix_the_mac, Groklaw
Sorry, I have just re-read the article and see that you have covered this quite fully.
Time to take a stand and support ODF in actions. See http://www.anyofficesuite.org .
What is silly is that you are suggesting one would use a representational date format for use in spreadsheet. You better tell me that Opendocument uses an alternative date format for spreadsheet or I’ll cry.
Also it is pretty clear that the ODF spec allows for ambedding of any arbitrary filetype whatasoever via xlinks for instance. That mean that you could in theory create an ODF document that consist entirly of an OOXML embeddend document.
The fact that OOXML has the possibility to do OLE embedded linking seems pretty simular.
Simular to ODF you could ignore any embedded objects if there is no support for the format present.
The only thing you can say is that OLE embedded links will be not be very crossplatform but it does not require any embedded format to be part of the format just as ODF does not have any possible embedded format in it’s spec.
ODF specification
paragraph 9.3.5 Plugins
A plugin is a binary object that is plugged into a document to represent a media-type that usually is not handled natively by office application software.
Is that not the same that happens with OLE embedded objects.
Mayby you should retitle the article the contradictory nature of both OOXML AND OpenDocument ?????
In ODF Java applets are defined as a native part of ODF documents.
I guess that is Sun’s way to require that any full implemention of the ODF spec needs a Java Virtual Machine to be present ????