David Wheeler, the chair of the OASIS ODF Formula Subcommittee has a good status update on our work defining the details of the expression language and supporting functions used in spreadsheet formulas. I’d also like to point out some cool work by Daniel Carrera, who put together some code that post-processes the OpenFormula specification (in ODF format, of course), extracts the details of the embedded test cases, then automatically generates an ODF spreadsheet file which executes the spreadsheet functions and verifies correct results. This resulting spreadsheet allows an implementation to automatically test their compliance to the spec. This gives us a self-testing specification, a great labor savings, as well as a demonstration of the innovative things you can do with ODF. Details are here.
(I note in passing that although the OASIS ODF TC does all of its working documents in ODF format, the Ecma TC45 does none of its working documents in OOXML. They continue to use the old proprietary Microsoft binary formats as their working format on the TC. A suggestion — If they are unable for some reason to use OOXML, then I encourage TC45 to use ISO ODF. They can then download Daniel’s code to help generate test cases from their spreadsheet formula documentation and this, I promise you, will save implementors a lot of time.)
Of course, malcontents will never be pleased by our progress, and will portray this progress as proof that we are yet imperfect, and therefore not useful. The first point is obvious, but the second is dubious.
Stephen McGibbon’s blog entry of a couple weeks ago seems to be the Urquelle of this particular line of reasoning. Here’s one small quote:
I mentioned that in my opinion, Sun were completely aware that ODF wasn’t sufficiently defined to support spreadsheet interoperability as long ago as February 2005 and that the realpolitik inside OASIS was to take advantage of the EU IDA’s request to standardise by rushing to be first despite knowing the ODF specification was deficient in at least this area.
Read the rest of his article and you’ll walk away with two misconceptions:
- The lack of a spreadsheet formula definition in a file format documentation is unusual, defective and prevents interoperability
- Spreadsheet formulas were left out because ODF standardization was rushed, for political reasons
Let’s take a look at each of these in turn.
First, let’s look at the state of the art in spreadsheet file format documentation over the years, with particular attention to how spreadsheet formulas have been documented. As the following table shows, Excel formulas have never been publicly specified, even though Microsoft has been producing file format documentation for various binary, HTML, XHTML and XML Excel formats for over 9 years. It was only after the ODF TC decided to document our spreadsheet formulas and formed a Subcommittee to do so that Ecma TC45 decided to follow. The FUD followed soon after.
| Date | Format version | Formula status |
|---|---|---|
| 1997 | Excel 97 Developers Kit (Microsoft Press, 1997) | not defined |
| ca 1998 | MSDN CD’s in this era had Office file format documentation | not defined |
| Jan 1999 | Office 2000’s XHTML formats for Excel | not defined |
| May 2001 | Office XP’s XMLSS format for spreadsheets | not defined |
| Nov 2003 | Office 2003’s XML Schemas | not defined |
| Dec 2005 | Microsoft submits initial “base document” to Ecma | not defined |
| January 2006 | Ecma TC45’s Working Draft 1.1 | not defined |
| February 2006 | The OASIS ODF Formula Subcommittee is formed to add formula definition to the ODF specification | |
| April 2006 | Ecma TC45’s Working Draft 1.2 | not defined |
| May 2006 | Ecma TC45’s Working Draft 1.3 | Mirabile dictu! After 9 years of ignoring it, Microsoft finally decides to start defining their spreadsheet formula language. |
So the statement that the lack of a formula language specification is unusual or makes interoperability impossible falls down in the face of 9 years of contrary evidence. Over the years, the industry has managed to have interoperable spreadsheet formulas between different versions of Office as well as between Excel and competing spreadsheets, including 1-2-3, Quattro Pro, OpenOffice, StarOffice, etc., all without ever having a formula specification.
Even though every other spreadsheet file format specification in the past decade failed to document a spreadsheet formula language, the ODF TC knew that we could and should do better. That is why we took the lead and formed a Subcommittee to define, in great detail, with test cases, how spreadsheet formulas, expressions and functions should be interpreted. This is not fixing a problem. This is advancing the state of the art in file format specifications.
They say that imitation is the sincerest form of flattery. If so the ODF community should be blushing with all of this flattery heaped on it. If it wasn’t for the continual market pressure that our innovations bring, Microsoft would never have 1) issued a patent covenant for OOXML, 2)brought OOXML before a standards body, 3) started to document their spreadsheet formula language or 4) started to create an ODF Add-in for Office.
So, then what about the statement that ODF was rushed through the standardization process?
Let’s look at the numbers. Both ODF and OOXML are derived from pre-existing formats . This is not necessarily a bad thing. This is one source of “implementation experience” and this is beneficial to any standard to have this. But only once the “base document” is submitted to a multi-vendor open standards development organization (SDO) does the true work of standardization begin, including deep technical review of the specification to confirm completeness, conciseness, lack of ambiguity, correct use of formal specification language, ensuring platform independence, encourage flexibility and extensibility, etc. So, I’ll start the clock when the base specification is submitted to the SDO, and stop the clock when the SDO approves the standard.
The ODF numbers are clear enough since the 1.0 version is complete. The OOXML numbers require some estimation, since they are not complete, but I’ll justify my estimates this way:
- The OOXML Working Draft 1.3 is currently 4,081 pages long. At the SC34 meeting in June we were told by the Ecma Secretary General that more material was coming and that this draft was only 2/3 complete. By my calculations, this gives a final size estimate of around 6,000 pages.
- Predicting the completion date is harder. But we do know that Ecma specifications can only be approved twice a year at Ecma General Assembly which are in June and December. If I were Microsoft I’d really really really want OOXML approved in time for the Office 2007 launch, so I’m predicting Ecma approval will be sought at the December Ecma General Assembly.
Of course I could be wrong on either or both of those estimates, but let’s see where the logic takes us. The following table summarizes the time under standardization as well as the rate of standardization (pages/day) for each specification.
| Standard | Submitted to SDO | Standard issued | Days elapsed | Standard length | Rate of work |
|---|---|---|---|---|---|
| ODF | 12 Dec 2002 | 1 May 2005 | 867 | 706 pages | 0.8 pages/day |
| OOXML | 15 Dec 2005 | 31 Dec 2006 (est) | 381 (est) | 6000 pages (est) | 15.6 pages/day (est) |
Now I ask you, who is rushing? ODF took 2 ½ years to standardize 700 pages. Microsoft is trying to standardize a 6,000 page behemoth in just 1 year. I think the argument that ODF was rushed through under political pressure just doesn’t stand up to even cursory examination. Honestly, I think this FUD is being spread around as a smoke screen to hide the fact that OOXML is the one that is really being rushed.
Very impressive work. ODF 1, FUD 0!
McGibbon’s post just pointed out that Sun was aware that the ODF spec was incomplete but decided to standardize then fix the missing bits. That seems to be what’s happening now. I don’t see any FUD in his arguent.
Perhaps you doth protest too much?
Little old me, protesting too much? Trust me, I’m just getting warmed up.
I’d respond on the substance of your comment, but in all honesty I cannot discern your point. Did you really read McGibbon’s post and came away thinking that he was merely pointing out a fact about the ODF spec? Really?
It is obvious that cuurrently each software developer can createvery baisc non-interoperable ODF spreadsheet files that still conform to ISO standards. That is laughable. I wonder why OASIS did not wait with standardization untill the formula’s committe was ready.
If fact OASIS fasttracked the standardization which seems weird for an untested standard that has not been implemented or used anywhere.
I find it very reasonable when it is argued that the OASIS foudatin rushed the standardisation proces being presurred by Sun and the european union and even IBM.
Also I seem to remember that the OOXML format was always going to have the spreadsheets in them they just weren’t finished for draft 1.1. Your timeline seems FUD created to hide that OASIS was extremly late in recognising the importance of the formula’s in spreadsheets as effectivly untill formula’s exist in the format it cannot really be called interoperable at all.
Further more you are saying that ECMA TC produces none of it’s working documents in the OOXML formats. This is weird as the entire draft is available for many months in OOXML on the Ecma international site.
http://www.ecma-international.org/news/TC45_current_work/TC45_available_docs.htm
In fact I have never seen that draft in an old .doc format.
It seems you are trying to spread pure FUD !!!
OFD untested and unimplemented? Have you not heard of OpenOffice or StarOffice? They were both developing ODF support concurrently with the work on the specification. ODF 1.0 schedule pressured by IBM? IBM was not even involved in ODF 1.0 — we joined after. You might want to do some research and cite some evidence before repeating similar claims.
In any case, I’ve already shown how OOXML is being rushed through standardization at a rate several times faster than ODF. That’s a fact, not FUD.
My timeline hides nothing. Microsoft went 9 years without specifying spreadsheet formulas, not even in the 2003 Reference Schemas they recomended for Massachusetts or the base document they submitted to Ecma. They only started adding formulas after we started similar work with ODF. That’s a fact, not FUD.
I stand by my statement that the Ecma TC45 does none of its working documents in OOXML format. I’ve seen the complete list, all 320 (at last count) working documents, drafts, presentations, agendas, minutes, reports, etc., of the TC. None of them are in OOXML format. They are all in the old binary formats. The specification parts themselves are circulated and reviewed by the TC in the binary DOC format. That’s a fact, not FUD.
Albert, a question for you, exactly what other spreadsheets applications is the OOXML format compatible with? Please name at least three.
“. . . an untested standard that has not been implemented or used anywhere.”
Your statement is inaccurate. ODF was derived from the StarOffice/OOo file formats that had been in wide use for years. Moreover, your statement is not qualified as to time. As stated, it argues that there are not even yet any apps supporting ODF, which is ridiculous. See for example, the supporting applications database at OpenDocument Fellowship.
On the other hand, one can only predict widespread support for Microsoft’s XML formats by assuming that virtually all of the developers who have put years into developing apps using Microsoft Office’s APIs are suddenly going to decide to jump ship on those APIs and rewrite their apps to support the new file formats directly.
I wouldn’t advise holding your breath while waiting for that fantasy to come true. The Microsoft XML formats, IMHO, are just part of a translation layer created so MS Office has a shot at surviving a bit longer in emerging SOA environments without rebuilding the Office apps to support XML in their internal processes.
As someone who has worked with standards organizations, the fact that a standard gets voted on and approved without being able to provide full interoperability is probably not uncommon.
All useful standards are eventually revised. Politics and market pressures play a part in getting standards released; should we instead always wait for perfect? In any case, this makes it possible for companies to be involved with the standard’s development both to inspire and be inspired in the development of parts that do not yet meet the needs of their application.
As a bystander in this whole debate, I can only ask these questions:
Can the current ODF standard (or whatever version that will be available when Office 2007 ships) be used as the default format for Office 2007 (Word, Excel and PowerPoint) and fully preserve all features used in the applications?
If not, would this have been possible in the same timeframe if Microsoft had decided to join the ODF standards process at the outset?
If the answer is yes to the last question, would Microsoft have been allowed to make the needed changes to ODF before it was ratified as a standard?
Hi Ray,
Thanks for the interesting questions. The answer to both is “Yes”.
It is entirely possible to implement ODF 1.0 in all versions of MSOffice dating from 1997 through 2007. The ODi Plug-in that is now working it’s way through the Massachusetts RFi trials conclusively proves this.
It is possible to have perfect fidelity between MSBinaries and ODF 1.0, and still be conforming with the ODF 1.0 specification. There is however a trade off. Perfect fidelity within MSOffice does compromise somewhat the interoperability with other ODF 1.0 compliant applications. For applications not fully compliant with ODF 1.0, the interop compromise is more serious. Let me explain.
One of the first actions the newly formed OASIS Open Office XML TC (technical committee) took was to insure high fidelity conversion with the legacy of MSOffice documents. It’s called the -alien attribute-, and it was designed to allow the pass through of encoded elements spawned by features that could not be mapped to features covered in ODF 1.0. The proposal was crafted by the legendary Microsoft binary reverse engineering expert, Phil Boutros (Stellent).
Honestly, IMHO, there is no human being alive today who has more knowledge and expertise with MSOffice binaries than Phil. In fact, i’ve insisted over the years that Microsoft could not have found better representation on the OASIS Open Office XML TC than they got from Phil Boutros.
The -alien attribute- guarantees that unique features can be captured and fully expressed in ODF 1.0. The challenge for the ODF Community is that, as we capture and study these encoded expressions, we also figure out how to map them to ODF 1.2 so that full interoperability at perfect fidelity is possible. This “mapping” capability is very much the work of the ODF Metadata XML::RDF Sub Committee.
If you listen to the blather pouring out of Redmond concerning this perfect fidelity with the billions of legacy MSBinaries, you would think this to be an insolvable problem. Indeed, this rational is used as the primary excuse for Microsoft not being more active in the Open Office XML specification process than they were. Yes, “than they were”. Since day one Microsoft has been a fully registered member of the OASIS Open Office XML TC, and has had total access to all discussions, conferences, documents and list serves. As to their actual role in the Open Office XML process, one would have to say that Microsoft contributed nothing and took everything. The individual representing Microsoft is Mr Rabih Filfili, , Phone: 650-693-2237, rabihfi@microsoft.com
About the blather; the claim that Open Office XML was developed without concern for the billions of legacy MSBinary documents is pure Microsoft FUD. They know damn well the concerns we had.
So, is high fidelity with the fabled “billions of MSBinary documents” possible without also compromising interoperability? The answer is yes, but not with the ODF 1.0 specification. With the ODF 1.2 iX version of the specification, the answer is yes; a big booming resounding yes promising with certainty perfect fidelity and round trip perfect interoperability.
The ODi Plug-in will have MSOffice fully compliant with ODF 1.2 iX by January, 2007. The other part of the high fidelity – interoperability equation is that other desktop, server, and device side applications are also ODF 1.2 iX ready.
The current crop of ODF 1.0 ready applications will still be able to fully process ODF 1.2 iX documents, but they will not be able to improve their fidelity of conversion and interoperability beyond it’s current state; at least not until the transition to ODF 1.2 iX is made. To accelerate this transition to ODF 1.2 iX, the OpenDocument Foundation and the OpenDocument, Inc. development group is working to provide a run time and ODF InfoSet API able to fully access the conversion, processing and layout aspects of the plug-in’s core high performance engine.
About ODF 1.2 iX:
So, what is this ODF 1.2 iX version of the specification? And how does it get us to high fidelity and complete roundtrip interoperability?
Good questions. Before i answer though, i would like to briefly explain the terms “high fidelity” and “roundtrip interoperability”. Because there are billions of legacy MSBinary documents out there, high fidelity first and foremost pertains to perfect fidelity between those billions of binary documents and conversion to ODF.
The term “roundtrip interoperability” in this context refers to holding or maintaining that high fidelity as ODF versions of these documents move between desktop, server and device applications that are ODF 1.2 iX ready.
Microsoft of course has traditionally only offered limited roundtripping with their binary file formats. A tradition that continues with MS Office Open XML. Many refer to this limitation as “version madness”, meaning that the only way a workgroup can “continue” to exchange documents is if everyone is running the same version of MSOffice. Legacy documents can be upgraded to the latest version of MSOffice, but document originating legacy versions of MSOffice are unable to read them in again once they’ve been corrupted by the latest greatest MSOffice version. It’s a one way compatibility demand. We’re not talking about a degradation of fidelity here either. Legacy documents pushed forward to latest greatest MSOffice can’t be opened by originating applications on return. A mere loss of fidelity would be welcomed under these costly and disruptive circumstances. And the upgrade treadmill chugs on to the tune of $24 Billion dollars per quarter.
OBTW, the ODi Plug-in puts an end to version madness. MSOffice 97 can send documents to MSOffice 2007, and be able to read them in when they come back again. Perfect round trip interoperability. Just set the default file format to ODF, get off the madness of the upgrade treadmill, and never look back again.
Okay, about ODF 1.2 iX. Following the May 2005 OASIS approval of ODF 1.0, the roadmap to the 2.0 version was gradually split into three OASIS ODF TC sub committees; Accessibility, OpenFormula, and Metadata XML::RDF. OpenFormula and Metadata work actually began in 2004, but these objectives were not a formally stated part of the ODF 1.0 blueprint. The preparation of ODF 1.0 for ISO consideration also began in 2004, with the final ISO ratified version known as ODF 1.1.
The work of the three sub committees is expected to be complete by the time ISO ODF 1.2 is issued for public comment. Since the OpenDocument Foundation sponsors many of the open source community related contributors to the ISO ODF process, and indeed occupies a prominent position in the burgeoning OASIS consensus driven standardization process, we know exactly what is happening in the sub c’s and why. And since our ODi Plug-in works inside MSOffice, where we have a very unique view of those MSBinaries, we are actively testing and implementing the ODF 1.2 proposals at the epicenter of the wheelhouse where those billions of binary documents will pass.
At this point in time, we are certain that the ODF 1.2 proposals will go a long way towards solving the high fidelity – roundtrip interoperability problem set. All that’s missing from the ODF 1.2 work is a small group of -interop eXtensions-, which the Foundation will propose to the ODF Metadata XML::RDF SC. This is the “iX” in ODF 1.2 iX. Currently there are only five -interop eXtensions-. Maybe we’ll need two more. But the odds are very good that these five will finish the job of high fidelity with perfect round trip interoperability.
Five -interop eXtensions-. Sounds impossible. Especially with the torrent of FUD pouring out of Redmond. For the sake of five simple eXtensions, Microsoft opted out of participating in the OASIS Open Office XML work. By January 2007, this will be clear to everyone.
Microsoft’s first response to OASIS Open Office XML was with their own version of proprietary MSXML that featured a separation of content and presentation. Sadly the initial version locked the presentation aspects in a binary format that only MSOffice Applications could unlock. After much complaint, they changed that. Still, the family of MSXML file formats were heavily encoded, and there was no blueprint for deciphering this. Nor guarantee that anyone attempting to do so wouldn’t be sued royally.
During this time frame, there was the famous EU TAC/IDABC Valoris Report and request for comment. IIRC, the responses from Microsoft , Sun, and IBM were posted and countered during the summer of 2004. When all was said and done, both OASIS Open Office XML and MSXML were forever changed. And changed for the good.
Microsoft assured the EU that they would come out with an open XML file format, and submit it to a recognized standards body. In 2005 they came out with MSECMA, officially naming the file format Microsoft Office Open XML. Not to be confused with the OASIS Open Office XML. Since this is so confusing as to be beyond deceit, most refer to MSECMA as MSECMA or MOOX. Microsoft insists on calling it Open XML or Office Open XML. Even though by their own admission, MSECMA was designed solely for the needs of MSOffice 2003 and MSOffice 2007. By design, MSECMA has zero interoperability with any other non Microsoft productivity application.
In the August – September time frame of 2004 EU IDABC Valoris controversy, OASIS Open Office XML changed also. The EU demanded support for XForms. They got it. They insisted on submission to ISO for ratification. They got it. They asked us to address the Microsoft framed issue of “custom defined schemas”. XForms and the XML::RDF Metadata model smashed that issue to bits. And they asked us to change the name to accommodate complaints from Microsoft. They got that too. The name was changed from “Open Office XML” to “OpenDocument”. This despite concerns on the TC that Microsoft would soon enough take the name “Open XML”. They did. And also that there would be confusion between the OpenDocument portable document model, and the failed “OpenDoc” portable component model. There was.
Interestingly, there was no issue concerning a standardization of formula’s. Microsoft didn’t bring it up in their complaints about Open Office XML. Nor did they offer it in their own 2004 MSXML proposal. And they threw everything they could think of at us.
Nor did the Valoris Report specify work on Formulas. And what an exhaustive study that was! The Massachusetts ERTM didn’t specify formulas. In August of 2004 when the Open Office XML TC first began working in earnest with ISO on the submission, there was no mention of Formulas. Formulas weren’t in the ODF 1.0 roadmap, and for first one and a half years of public and community specification work, no one thought about it. As Rob points out, for nine long years Microsoft never once brought up the idea. Now they consider the lack of a formula standardization in ODF 1.0 to be an oversight of the greatest offense against mankind. What does that say about their behavior for the past nine years?
Honestly, no one brought up the idea (it wasn’t an “issue”) until David A. Wheeler made his fabled proposal in September of 2004. At the time the idea of standardizing formulas was such a foreign and perhaps “impossible” concept, only a David A. Wheeler would dare dream such a thing. Not only did he dream it, he organized the resources and participants and went about the difficult task of doing the unthinkably impossible. With lots of help from the OpenDocument Fellowship, David and his troupe are now very close to pulling it off. By November i think the OpenFormula SC delivers, and ODF 1.2 will represent an incredible milestone in the history of computing.
One reason Microsoft gave the EU for not supporting Office Open XML file formats in MSOffice, when they had traditionally supported so many others, was that Microsoft didn’t want to use a file format named after their primary OSS competitor. I guess it’s okay to have a WordPerfect commercial competitor file format conversion, but not an OSS competitor. Whatever. Frustrated, the EU asked the Open Office TC to change the name, thereby taking the issue off the table for anyone making similar noises as the Microsoft whine. We did. I hope however that the many members of the ODF Community will continue to refuse to dignify the deceitfulness at play here. MSECMA or MOOX is as far as i will ever go. I’ve only used the term MS Office Open XML in contrast with OASIS Open Office XML to demonstrate the deceit and resulting marketplace confusion at work.
In summary, the answers to your questions are:
Can the current ODF standard (or whatever version that will be available when Office 2007 ships) be used as the default format for Office 2007 (Word, Excel and PowerPoint) and fully preserve all features used in the applications?
Yes. The ODi plug-in proves that one can set the default file format to ODF, and fully preserve all features. This preservation includes all features available through business process and assistive technology add-ons to MSOffice. So native MSOffice features and developer platform added features are all preserved in ODF, and preserved with perfect fidelity possible. I say “possible” because round trip interop with ODF 1.0 ready applications can’t preserve or reflect that same high fidelity. That’s why we have ODF 1.2 iX. I promise you Ray, with ODF 1.2 iX you will have high fidelity and perfect round trip interop.
If not, would this have been possible in the same time frame if Microsoft had decided to join the ODF standards process at the outset?
The high fidelity with billions of legacy MSBinary documents was made possible within the first few weeks of OASIS Open Office XML discussions. The alien attributes capability is one of the first official consensus driven changes made to the Open Office XML specification. If Microsoft had decided to contribute as well as take, for sure we would have perfected early on the identification and mapping of these feature specific attributes. They know exactly what happens inside MSOffice. We didn’t share in that same viewpoint until the ODi Plug-in got inside MSOffice, and began to gather together an entirely new understanding of how MSBinaries work. Within six months of this new viewpoint, we had our five interop eXtensions. These things are a no brainer for anyone actually designing and implementing the binaries, building the application feature sets, and provisioning the developer platform with the exact API’s needed to create new features.
If the answer is yes to the last question, would Microsoft have been allowed to make the needed changes to ODF before it was ratified as a standard?
Yes. OASIS is a consensus driven standardization process. The billions of legacy documents locked into MSBinaries was a primary concern for the OASIS Open Office XML TC. Long before the advent of the OASIS Open Office XML effort, these high fidelity conversion of these documents had been the primary concern of all MSOffice competitors and alternative providers. It’s always been a primary concern for OpenOffice.org. The truth is that fidelity of conversion and round trip interoperability with MSOffice has long been a make or break differential for any other competing alternatives.
One last point Ray. Although you didn’t ask about it, allow me to tackle two more MS FUD points; performance and accessibility add-ons.
About Performance:
There is no doubt a performance differential between MSOffice applications, and OpenOffice.org applications. But then, MSOffice has always been able to out perform all desktop productivity suite competitors. Such are the advantages of having direct and highly privileged access to the Windows Operating System.
So we can’t fairly examine the performance differences between MSECMA, MSBinaries, and ODF if the test application suites have known performance differentials. And since we can’t test MSECMA in OpenOffice.org, we can’t use OOo as part of our performance examination.
However, since the ODi Plug-in does run inside MSOffice, we are able to perform an application neutral test of MSECMA, MSBinaries and ODF. In fact, this was an important part of our demonstration to Massachusetts and the EU IDABC. We ran the clock for them proving conclusively that performance is near entirely an application issue. Once you neutralize the application differential, the performance differences between MSECMA and ODF file formats prove to be insignificant and inconsequential.
Okay, so what does “insignificant” mean? Well, there is no indication that one file format has a distinct performance advantage over the other. And both XML file formats are surprising close to MSBinaries in performance.
Let me give you an example. When we demonstrate the ODi Plug-in, one of our test documents is a million row Excel spreadsheet commonly used to stress test applications. It’s a monster.
Because of the way MSOffice applications use cache memory, you really have to do multiple loads, comparatively timing each one in sequence. The more time MS gets to load a document, the faster the applications can do it. The ODF version of the monster spreadsheet always held the initial performance advantage by significant margins, upwards of 12 seconds. The MSECMA performance began to close this gap with the second and third loads, as the special caching features set in. ODF never once lost it’s performance advantage, although the difference was down to the 1.5 second range – (otherwise known as the who cares range).
As we learned more about the cache process though, we are able to enhance the performance of the ODi Plug-in, once again proving this isn’t about the file format! With subsequent enhancements, we were able to hit a 28 second performance differential. Again, let me emphasis, it’s not about the file format, and all about the application level of understanding and configuration. There is no doubt in my mind that Microsoft could come back in and tweak MSOffice to once again close the performance gap between MSECMA and ODF.
The conclusion here is that applications drive performance, not XML file formats! Any differences we found would simply not qualify as show stoppers.
One last thing about performance and our presentation to the EU IDABC Experts Group in Belgium, July 5th. Microsoft attended this meeting, and got to see the ODi Plug-in up close and personal, installed and running in different versions of MSOffice. They got to see the performance clocking. They got to attend a lengthy question and answer discussion with the IDABC Experts. On the morning of July 6th, the following day, Microsoft pulled the wraps off their own hushed and very secretive one way conversion “plug-in” project.
Of course, we don’t know if it was this presentation of the ODi Plug-in to the EU IDABC Experts Group that inspired Microsoft to take the wraps off their secret project. What we do know though is that immediately following our presentation, Microsoft asked the EU IDABC director Barbara Hale for a closed session with the group. Since the Experts Group meeting was already a closed session, “closed” in this sense meant that we were asked to leave the room. At that point, Microsoft informed the group of their intentions to take the wraps off their open source plug-in effort the following day.
One can only guess at the motivations at work here. But the timing is suspect. (The terms “cut off their oxygen” and “choke them in the crib” comes to mind, but the ODi Plug-in is nowhere near the threat that Netscape presented. Or is it? :)
About Accessibility:
OpenOffice.org, KOffice, WorkPlace, NeoOffice, and Novell Office might have problems with assistive technologies in that few if any of the accessibility vendors are writing to these applications. Yet! That situation is certain to change over time.
The real question is what to do about migrating to ODF today, and do so without costly disruption to MSOffice bound business processes or assistive technology add on solutions? This my friend is where the ODi Plug-in comes into play.
Since the ODi Plug-in operates entirely inside MSOffice, there is no disruption or interference with MSOffice bound business processes or accessibility add ons. Nor is there a performance overhead or loss of fidelity. Whatever a MSBinary can do inside MSOffice, the ODi Plug-in can do in ODF. There simply is no accessibility issue whatsoever. Lots of concern, but concerns based entirely on fears generated by Microsoft as a means of stopping the implementation of ODF solutions.
I for one am appalled that Microsoft would resort to such tactics. We’re all used to MS FUD and their crush any threat to their profit stream at any cost mentality, legal or not. But common! The accessibility challenged community has fought long and hard just to gain some small measure of participation in the emerging digital information civilization. Even with the most advanced assistive technologies, that participation is difficult beyond belief. It is only through the most incredible determination and relentless driving desire that this community can make use of computer systems. What they do with the meager array of information tools available, and the hurdles they are able to cross, is simply spectacular. But shouldn’t it be the other way around? Shouldn’t digital technologies greatly improve their access and participation? All i see are barriers and hurdles, most of which are the direct responsibility of the great monopolist from Redmond.
Just because there are billions upon billions of dollars to be made from the Windows graphical user interface should not mean that the accessibility challenged community be left behind! And now that same monopolist is filling that same community that has fought long and hard for a few meager concessions from the graphical over lord, filled them with the unfounded fear that ODF represents yet another insurmountable hurdle. And none of this is true.
More appalling behavior from the master of reprehensible business practices. What else is new?
~ge~
Hi Anonymous,
You argue that McGibbon is right in saying that, ”Sun was aware that the ODF spec was incomplete but decided to standardize then fix the missing bits”.
How do you know that Sun valued the standardization of formulas, and thought that effort to be a necessary part of the ODF 1.0 specification, but left it out on purpose so as to rush the file format to ISO? Where would you ever find corroboration of this information?
You and McGibbon talk as though Sun had planned all along to have a single ODF 1.0 version of the Open Office XML specification, complete in every way; push it through OASIS and ISO; and once ratified pack it up and go home because there’s nothing left to do?
Surprising as it may seem, the work on ODF is expected to last generations. The Open Office XML 1.0 specification was just the beginning. The 1.0 objectives were kept to a minimum because the consensus process among multiple vendors, users, organizations, governments, developers and open source communities was thought to be far more important a first achievement than trying to get everything every human being on earth would want of a portable document – universal file format designed to be in service to mankind for at least the next 200 years.
Since Microsoft standards are not consensus driven, the difficulties of what ODF is trying to accomplish perhaps escapes you. MSECMA seeks only to meet the portable document needs of Microsoft applications, frameworks, and platforms. Incredibly limited objectives, but doable. Being able to dictate whats what is a luxury only Microsoft enjoys.
ODF has to meet the needs of those same Microsoft applications and platforms, as well as the needs of all other applications and platforms. We simply don’t have the option of ramming crap down everyone’s throat simply because it’s what one vendor wants; monopolist or not. Everything with ODF is done by consensus and public peer review.
The ODF 1.0 specification work was split into two phases. Work began in November of 2002. It was only when David A. Wheeler approached the OASIS Open Office XML TC in September of 2004 that the issue of Open Formulas was raised. Sun’s representatives on the Open Office XML TC examined David’s proposal along with everyone else. Most of us thought the idea was great, but far outside the reach of reality. Personally i thought it was an impossible task. Sun to their credit thought success would border on the fringe of being nothing less than a miracle, but they were willing to give it a try. The entire TC agreed however that the first order of the day was to stay the course with our ODF 1.0 objectives, and take up both the OpenFormula and Metadata work in the ODF 2.0 push.
This was hardly the sole decision of Sun. Our decision was unanimous. No one looked at ODF 1.0 as being somehow ”incomplete”. We simply saw this as the best way to move forward and keep our current obligations.
Anonymous, you talk as though at one time you thought perhaps that Windows 95 would be the last OS ever produced. So complete that who would ever dream of improving it over time. Does the existence of Windows 97, 98, 98 SE, 98 ME, 2000, XP, XP 2003, and Vista mean that Microsoft deceived the world in 1995, knowingly releasing into the marketplace an unfinished product? A product missing critically important features that they are just now getting around to including?
When Sir Timothy first gifted HTML 1.0 to the world in 1989, should we now fault him that HTML 1.0 didn’t include all the features we now have with HTML 4.0, CSS, XHTML, XML, XSLT, XForms, XQuery, XPath, SVG, and ODF? What if we had insisted that Sir Tim not gift HTML 1.0 to the world until it’s complete? Maybe put the Internet revolution off until say, 2012? Should we now accuse Sir Timothy of submitting an incomplete standard because even as far back as 1989 he imagined the Semantic Web, but gave us instead HTML 1.0?
This kind of thinking is beyond insane. It’s filled with fear, hate and slander.
Sure, in the autumn of 2004 when David first suggested it, everyone thought it would be nice to have an open formula layer. For as long as there have been spreadsheets, this has been the Holy Grail. Reaching consensus amongst 25 years or more of spreadsheet providers and experts makes the effort to find the Holy Grail look as trivial as a trip to Walmart. This is an impossible challenge! Or so it seemed. David A. Wheeler was somehow up to the impossible challenge. And now he’s done the unthinkable. He’s about to deliver the Holy Grail of spreadsheet computing.
One of the reasons it’s unthinkable for the Open Office XML effort is that ODF is a multi application, cross platform universal portable file format. We have to find consensus amongst all the participating spreadsheet applications. Which goes pretty far back considering that Dan Bricklin, the inventor of the spreadsheet, is also an OpenFormula participant.
Microsoft doesn’t have to reach consensus with anyone. For them it’s a simple process of deciding to publish their Excel formulas. That it took them nine years to make this decision is something to think about. That they were starring down the David A. Wheeler gauntlet, looking at the Holy Grail itself, when they came to this supposedly altruistic moment of largess and sudden good citizenship, righteously admonishing us that every open standard should include formulas speaks volumes about their true intent and character. Do you honestly expect anyone to believe that over the past nine years Microsoft had been planning all along to provide their formulas in a public way? You’ve got to be kidding.
So if you have any proof or corroborating evidence that backs up the spurious statements of that FUD slinging low life McGibbon, let’s hear it. Because i was there. I know what happened. If i’m mistaken, let me know with facts. Otherwise, stop with the lies.
~ge~
Hi Gary
Wow. Thanks for that response. I think I got a bit more than I bargained for when I asked the question :)
As I said earlier, I am an interested bystander to this whole debate, rather than an active participant, but look forward to the day when there are actual shipping products that we can use to seemlessly interoperate.
Do you mind if I repost your reply to Brian Jones’ blog for his commentary?
Ray
Gary:
“OpenOffice.org, KOffice, WorkPlace, NeoOffice, and Novell Office might have problems with assistive technologies in that few if any of the accessibility vendors are writing to these applications. Yet! That situation is certain to change over time.”
This is only partially true. That is, OO.o has trouble with assistive technologies on Windows–because the accessiblity design was so poor up until Vista (unless that slipped their release schedule too; I’ve no direct knowledge that it’s in or out) and required each application to be handled specially by the accesibility software/hardware. Under Unix, Linux, and MacOS desktops, this has not been the case for many years. (source is reading Peter Korn’s blog). There are some caveats about supporting certain disabilities, but these seem to be much less common.
So the solution is simple–dump Windows and use OpenOffice. ;)