ODF Spreadsheet Interoperability


Rob Weir posted on his blog a couple of days ago an Update on ODF Spreadsheet Interoperability.  I think it’s great that he has brought up spreadsheet interoperability, and specifically the issue of formulas, which seems to be the main thrust of his post.  I mentioned on the day of our SP2 release last week that “I’ll be doing some blog posts that get down into more of the technical details, to help explain some of the engineering decisions that we made in our implementation,” and Rob’s post is a good starting point for that conversation.

For those who only want to read the first two paragraphs of this very long post, here’s a summary:

  • ODF’s lack of spreadsheet formula syntax creates some interoperability challenges;   Because ODF 1.0 and 1.1 do not support formulas, all ODF spreadsheet implementations are application-dependent
  • We’ve worked hard to overcome these challenges in ways that provide accurate results and predictable interoperability
  • We have been fully transparent about the decisions we’ve made in our ODF implementation, both in terms of the guiding principles we’ve followed and also the specific details published in our implementer notes 
  • The Open Formula specification is not yet a standard, so we do not support it in its unfinished state, but we will look closely at Open Formula when it becomes a standard and make a decision then about how to best proceed

Before I get into the details, I think it’s worth noting that there’s nothing new here.  The challenges of ODF’s lack of formula specification have been around for a long time, and many people saw the current situation coming.

Nearly three years ago, Stephen McGibbon had a good post covering the situation, which is worthwhile reading for some background on how we got to where we are today.  As you can see from the quotes in Stephen’s blog post, many people in the ODF community – and the broader standards community – were dismayed at the decision to not include formula syntax in ODF.  Others outside of Microsoft also pointed out the problem years ago.  Rob’s blog post, as well as this post, are excellent examples of the sorts of interoperability challenges that those people saw coming as a result of the decision to not include formula syntax in the ODF standard.

Testing Methodology

The first thing I did upon reading Rob’s post was to try to follow his steps for myself, so that I could understand the context of his findings.  Here’s the methodology he describes in his post:

The test scenario I used was a simple wedding planner for a fictional user, Maya, who is getting married on August 15th. She wants to track how many days are left until her wedding, as well as track a simple ledger of wedding-related expenses. Nothing complicated here. I created this spreadsheet from scratch in each of the editors, by performing the following steps:

  • Enter the title in A1 "May’s Wedding Planner" and increased font size to 14 point.
  • Enter formula = TODAY() in B3 and set US style MM/DD/YY date format/
  • Enter the date of the wedding as a constant in cell B4, also setting date format.
  • Added simple calculations on cells B6-B8, to calculate days, weeks and months until the wedding.
  • A11 through E16 is a simple ledger of the kind that is done thousands of times a day by spreadsheet users everywhere. Once you have the formula set up in column E (Balance = previous balance + credits – debits) then you can simply copy down the formula to the new row for each new entry

Sounds simple enough.  So I fired up Open Office 3.0.1, and followed those steps.  The resulting spreadsheet looked like this:

image

Then I saved the document, by clicking File/Save and then typing in a filename:

image

So far so good.  Next step, I tried opening the document in IBM Lotus Symphony version 1.2.0.  Here’s what I saw:

image

And then I opened the same document in Excel 2007 SP2, and here’s what I saw:

image

This is a great example of a common ODF spreadsheet interoperability challenge, and two different ways of dealing with it.  The challenge is caused by the fact that Open Office writes formulas in a syntax that is unknown to Symphony and Excel.  Open Office, for reasons I don’t understand, has decided to use as their default formula syntax the unfinished Open Formula specification, which is neither approved nor published by OASIS – not even out for public review yet.

So what do Symphony and Excel do about this challenge?  The answer is that Symphony preserves the (unrecognized)  formula markup, and Excel preserves the cached values.  (A quick aside for those who don’t know: spreadsheets typically store both the formula and the value resulting from the most recent recalculation.)

Getting back to Rob’s initial premise of this being a typical wedding-planning exercise, if Maya were to send this spreadsheet to a person using Microsoft Excel SP2, that person would see the values as shown above.  They’d know at a glance what day was ‘today’ when Maya made the file, and that the ledger balance that day was 5500.

But if Maya were to send this spreadsheet to a person running IBM Lotus Symphony, they’d see only the formulas.  Perhaps an ODF markup expert like Rob would be able to massage that spreadsheet into something usable, but most people would find it a bit hard to conceive of what it means for a wedding to be “of:=B4-B3” days away, or for there to be a ledger balance of “of:=E15+C16-D16” dollars.

So what does Rob’s test matrix show for these two scenarios?  Oddly, it labels Open Office to IBM Lotus Symphony interoperability for this scenario as “OK” and it labels Open Office to Microsoft Office SP2 interoperability as “Fail” (with a red background for added emphasis).  Now, I know Rob works for IBM and probably wants to portray Symphony in the best possible light, but is that a reasonable assessment of the interoperability we’ve just seen above?

After further investigation, though, I think I see what Rob may have actually done to get the result in his table.  He seems to have included some steps that aren’t documented in his blog post:

  • In Open Office Calc, he went into Tools, Options, Load/Save, General.
  • For “ODF format version” he changed the setting from “1.2 (recommended")” to “1.0/1.1 (OpenOffice.org 2.x)”
  • The dialog then warned him that “Not using ODF 1.2 may cause information to be lost.”
  • He clicked OK to save the change.

Here’s how it looks, for those who don’t have Open Office handy:

image

After following these steps, Rob was then able to create a spreadsheet that stores formulas in the undocumented non-standardized syntax that was used by old versions of Open Office.  Symphony, being simply a fork of an older version of the Open Office code base, is able to understand those formulas, so it can load both the values and the formulas themselves.

It’s worth noting what the OpenOffice.org developers have to say about this option that Rob has apparently used for his interoperability testing:

image

So it sounds like there isn’t any single version of ODF that will provide compatibility across all versions of Open Office and Symphony.   You can use the “may cause information to be lost” option if you want to do a demonstration of formula interoperability with ODF, but if you want to demonstrate text-bullet interoperability, you may need to use another option.

And what does Excel 2007 SP2 do with the document saved in this alternative format?  Exactly the same thing it does with Open Office’s current default format: it displays the data, so that the document user can see the results of the last recalculation of the spreadsheet, and it ignores the formulas that are written in a non-standardized syntax that Excel doesn’t support.  I think that’s a pretty reasonable approach, when a spreadsheet application comes across non-standardized formula syntax: show the last recalculated result, thus preserving the data, and don’t try to guess at the semantics of undocumented formula markup.

Why Doesn’t Office 2007 SP2 support Open Office formula syntax?

That’s a logical question to ask, in regard to how SP2 handles formulas.  To answer it accurately and completely, we should distinguish between the two formula syntaxes that Open Office uses.

The first is the syntax they use in their non-recommended “1.0/1.1 (OpenOffice.org 2.x)” setting.  This is an undocumented, deprecated syntax, and therefore not a reliable mechanism for formula interoperability.  Despite what you may read on some blogs, it is not the same syntax as used by Excel 97/2000/2003.  Open Office copied quite a bit of the feature set from Excel, and there are definitely similarities in the formula syntax, but there are also differences with regard to referencing, operators, data types, and function arguments.

The other formula syntax that Open Office supports is the Open Formula syntax, which will eventually appear in ODF 1.2.  This syntax has not yet been approved by a standards body, nor has it undergone the 60-day public review period that OASIS requires prior to approval and publication.  It may go to public review soon, but it won’t be a standard until later this year at the soonest, and the details may change as a result of the remaining TC work and the public review process.  (According to recent discussions in the ODF TC, we may send the other parts of ODF 1.2 out for public review first, to allow more time to finish up Open Formula.)

In Office’s implementation, we haven’t chosen to support the draft Open Formula spec (as Open Office currently does), because we have certain obligations when we ship software that don’t apply to open-source projects like Open Office.  We need to test and verify behavior to a degree that’s not possible without final, fixed documentation that is believed to be 100% complete and accurate.  When Open Formula is completed, standardized, and published, we’ll be looking at that as the future path for enabling formula interoperability in ODF spreadsheets.  But we’re not there yet; ODF 1.2 is not done, and not even ready for public review.

It’s interesting to note that we have discussed this very issue at a DII workshop.  Last July, we had a workshop in Redmond, with attendees including other ODF implementers, members of the ODF TC, standards professionals, and others.  In the roundtable discussions, I brought up our approach to formula support as outlined above, and asked for feedback.  Although it was not 100% unanimous, there was clear consensus among most of the participants in the discussion that they did not want us to implement a non-standard formula syntax in anticipation of it becoming a standard.  “Putting the cart before the horse” in that manner was seen by many as a possible source of future interoperability problems, rather than a solution to them, and we took that feedback into consideration.

As I’ve covered before, we feel that thorough documentation of implementation details is a cornerstone of document format interoperability.  We’ve published detailed implementer notes for our ODF implementation, and on the matter of formulas (which are stored in the table:formula element), here’s what our implementer notes have to say:

The standard defines the attribute table:formula, contained within the element <table:table-cell>, contained within the parent element <office:spreadsheet \ table:table-row>

This attribute is supported in core Excel 2007.

1. When saving the table:formula attribute, Excel 2007 precedes its formula syntax with the "msoxl" namespace.

2. When loading the attribute table:formula, Excel 2007 first looks at the namespace. If the namespace is “msoxl”, Excel 2007 will load the value of table:formula as a formula in Excel.

3. When loading the table:formula attribute, if the namespace is missing or unknown, the table:formula attribute is not loaded, and the value “office:value” is used instead. If the result of the formula is an error, Excel 2007 loads the <text:p> element and maps the element to an Error data type. Error data types that Excel 2007 does not support are mapped to #VALUE!

And, as both Rob’s tests and mine show, that is exactly what Excel does.  It would be great if there were a place implementers could go to see these sorts of details for all major ODF implementations.

Summary

I’m glad to see this sort of public scrutiny of the details of ODF interoperability and how the underlying challenges are handled by various implementations.  As you can see, spreadsheet interoperability is a complicated topic, and in the specific case of ODF spreadsheets, there is even more complexity created by the lack of a defined formula syntax in any published version of ODF.

The good news, when it comes to formulas, is that the Open Formula specification will address this area soon.  My colleague Eric Patterson represents the Excel team in the Open Formula SC, and the very capable David Wheeler leads that group.  Much good work has been done already, and we look forward to seeing the final Open Formula spec go out for public review and then approval by OASIS.  The nearly 400 pages of formula syntax documentation in ISO/IEC  29500 (Part 1, section 18.17) enables reliable formula interoperability in the Open XML community, and soon the ODF community will have a similar level of formula interoperability.

But formulas are not the only ODF interoperability challenge.  As members of the ODF TC and also the OIC (ODF Interoperability and Conformance) TC, both Rob and I – and many others – will need to work together to enable better interoperability in areas including tracked changes, mail merge, application settings, and others.  Will ODF 1.2 be the most interoperable version of ODF yet?  I hope so, and there are signs that it will be.  But our work is not nearly done.


Comments (60)

  1. Jomar Silva says:

    Hi Dough !

    Seeing that I really admire you and respect your work, I’ll leave my own comments about SP2 to my own blog.

    I just want to contribute with your text about Rob’s Mary (if we can call her that way), and her experience with MS Office 2007 and ODF… It goes that way:

    "…And Mary needs to update her spreadsheet with more updated prices, and as a good and modern bride (yep, the lady uses ODF), she always carry that precious spreadsheet on her pen drive.

    Away from her computer and seeing that MSOffice 2007 now supports ODF, Mary uses a friend’s machine with MSOffice 2007 to update her spreadsheet.

    She open the document and fell very happy and comfortable when she sees "everything there", update a previous imputed price, and gets noticed that no new calculations are made… Seeing that she needs to give the machine back to her friend, she thinks "OK, I’ll solve that latter, let me just save my update to guarantee that I don’t lose the new price"… And she save (overwriting the original file) and close Excel.

    Latter on, when she arrive at home, she opens the document again and discover that all her formulas have magically disappeared !!!

    Crying and feeling sad about it, she thinks "Oh dear God, what my future husband will think about me, now that I was screwed by someone else….".

    Not a good end to Rob’s Mary tale, isn’t it ? (but a good "real world" use case about MSOffice with SP2).

    Best and cheers from Brazil,

    Jomar

  2. Rob Weir says:

    Doug, all of the spreadsheets I created and tested are in the zip file linked to from my post.  There are no additional "undocumented" steps involving saving OpenOffice 3.01 files in ODF 1.1 format.  I resent your insinuation that the test cases I used were otherwise than what I documented.

    My guess is your results differed because you used an older version of Symphony than the one I tested with.  My blog post explicitly states that I used Symphony 1.3.  You state that you used Symphony 1.2.  The goal of my test was to use the latest version of each application.  Using older versions is rather pointless, especially when the updates are free.  If you cherry pick versions then of course you will get different results.   If I wanted to play that game I could have picked the prior Excel 2007 SP1 and shown that it cannot load ODF documents at all.  But I think it is best like to show all applications in their most favorable light by using their latest versions.

    If you use the versions I indicated, the latest and greatest versions of the apps, you’ll get exactly the results I indicated, using the out-of-the-box defaults of the applications, with absolutely no tinkering required.   OO 3.01 spreadsheets are properly loaded by Symphony 1.3 and vice versa.  In fact, Symphony 1.3 spreadsheet formulas appear to be read properly by all of the ODF implementations I tested, except for Excel 2007 SP2.  It appears that some vendors actually work together for interoperability rather than just work on excuses.

  3. Doug Mahugh says:

    Hi Jomar, thanks for the kinds words.  The feeling is mutual.

    Regarding Mary’s spreadsheet, I think she’s actually in a very good position here.  Seriously, hear me out …

    Her future husband may have had concerns about the presence of undocumented formula markup in her document, which does not conform to any published standard.  He may have worried that this implied a lack of principles on her part; a questionable willingness to set aside open standards in pursuit of some other short-term objective.

    But now, he sees that she has removed that markup from her document, and it is 100% open-standards compliant.  And it still contains their data, the most valuable piece of the puzzle.  Hooray!  “Thank you, Mary,” he says, “for assuring that we will start our life together in true conformance to open standards, with no non-standard markup in our documents.”  And they live happily ever after. 🙂

    Of course, after Open Formula is published, the story could get even better!

  4. Doug Mahugh says:

    Hi Rob,

    First off, let me apologize: I didn’t notice that you were using Symphony 1.3.  My mistake.  I’m sure you can see how, with Symphony 1.2 installed (the currently available version from your web site at http://symphony.lotus.com/software/lotus/symphony/home.nsf/home), I had the experience that I did.

    So when will Symphony 1.3 be released?  Is there a way for me to get it now?  I’d love to do some interop testing with it.

    And regarding the good interoperability between Symphony 1.3 and OpenOffice 3.0 that you’ve described, you seem to be saying that that’s based on the unpublished, unapproved, not-yet-ready-for-public-review ODF 1.2 spec, correct?  What happened to the importance of conformance to open standards?  Does that matter this year?

    Oh, by the way — do you intend to update your test grid to reflect Kspread beta’s ability to interoperate with Office 2007 SP2?  Or does your testing methodology only allow for pre-release versions of *IBM* products?

    Cheers,

    Doug

  5. Gareth says:

    Hi

    I checked on the IBM web site too and could only find 1.2, so it’s not one of those Redmond IP filter tricks that some organizations have been known to employ 😉

    I might try this new approach with analysts:

    Monarch .next opens all formats on earth flawlessly, will pull in 1 TB of data in 5 seconds and make your morning coffee-it’s all in this table.

    Oh, you can’t repro that-well of course you can’t, you don’t have .next.  I explicitly stated you need it.  So there 😉

    So I suppose the only difference is that the defaults are different in 1.3 😉  If that’s really the only difference then I think we are all allowed a bit of a laugh at your outrage.  I hope there is a bit more to it than that.  A quick overview of the 1.2-1.3 changes that explain the new behavior would be good.

    Gareth

  6. Hi Doug,

    I find your arguments weak at best. Would a published, peer-reviewed standard be the best solution? Absolutely. Is it the only way to achieve interoperability? Of course not. Sometimes you have to simply mimick what other software does. Which is exactly what all other ODF implementations do. The only one that fails this formula test so miserably is Office 2007 SP2. Which shows the world that interoperability is possible, but it was not important (enough) to you.

    By the way, how did you manage to be interoperable with Lotus 1-2-3? A simple pointer to the published standard describing the document format (including formulas) is enough. Thanks.

    Stephan

  7. Rob Weir says:

    Doug, I’ll pass you name on to our beta program people and see if they can get you a copy.

    I’d be happy to add KOffice 2.0 RC to the list, and in fact I wrote to the KOffice guys before I wrote that blog post, to see if I could get them to run some test cases, but I didn’t hear back in time.  The structure of the test requires that I not only test KSpread/SP2, but test all of the other combinations involving KSpread and KSpread-authored spreadsheets as well.  When I have that info, I’ll update the table.  Ditto for any other product updates that come along.  The only one that is tricky is Google, since it is not obvious when they have updated their code.  It could be different an hour from now than it is now.  That’s the nature of the beast with web-based editors.  So to be safe I retest with them any time I re-test any other editor.

    The recommended approach is to conform with open standards where available and then do what ever additional work that is required to be interoperable, so long as that is not incompatible with conformance.  Using draft ODF 1.2 formulas in an ODF 1.1 document is still conformant to the ODF 1.1 standard.  First, your spreadsheet formulas are not conformant with the ODF 1.1 standard.  And second, you could have easily made them be both conformant and interoperable.  In fact you already have the code to do this from your ODF Add-in.  Using the excuse, "The standard made me do it" doesn’t cut it, since it is not true.  You could have been cboth onformant and interoperable.  But you ended up being neither.

    I’d suggest that all ODF vendors add Doug Mahugh to their beta testing program.  Microsoft clearly needs some help finding their way to doing interoperability testing _before_ they ship nonconforming ODF code to millions of people.

  8. @Stephan

    Hi Stephan – we have considerable experience in reverse engineering Excel binary formats and also in reading and writing OOXML spreadsheets.  The problem with aping the behaviour of canonical apps is that you can never be sure what pain updates will bring, or if observed behaviour is in fact a bug that is going to be fixed.

    In addition, if you are using subsets of functionality, you can’t be sure if mimicking the subset is acceptable to other mimicking apps, who may consider some functionality you don’t implement a required part of their own private, internal conformance rules.

    We have observed this behaviour in some applications that read XLSX files by trying to ape Excel 2007 behaviour, rather than the spec.  This has resulted in those applications not being able to read our valid, correct OOXML instances.  This is wrong and it is the path to madness.

    The "sometimes" you mention WRT mimicking apps is where there is no alternative, such as the old days of BIFF, where there was a spec, but it was somewhat outdated and badly documented.  With ODF and OOXML, the point is to try and leave those days behind.

    It appears that Microsoft are in a no-win situation here, as if they conform rigidly to standards they are lambasted and if they don’t they are lambasted.

    Perhaps if the people that feel they are qualified to be judge and jury about how Microsoft should implement standards in software could produce a guidance document with advice on when and where they should not be rigid, then that would probably help.

    Lotus 1-2-3 compatibility was "the old days" if you like.  People like Rob and the ODF contributors can take some of the credit for "helping" Microsoft to see the light, but you have to be careful what you wish for.

    BTW, if the documentation on the ODF support had been perused, this behaviour should not have been a surprise.  

    This all may sound like minor details to large organizations with big office suite implementations and huge resources at their disposal, but having decent standards in place really helps smaller vendors like us, who often only use targeted subsets of functionality.

    In the "old days" our exports could only reliably be read by Excel and to some extent OpenOffice (+clones) but with OOXML, the audience of consuming applications can grow far more easily.

    It’s like the old write once, (debug everywhere 😉 run anywhere story.  Our hope for OOXML is that it widens the population of consuming applications for our data exports.  Stab-in-the-dark application-aping is not something we can afford to do, or rely on other applications to do.

    @Rob I’m not sure what your phrase means: "conform with open standards where available and then do whatever additional work that is required to be interoperable, so long as that is not incompatible with conformance"

    Do you mean "conform with those parts of ODF that are defined, then do what OpenOffice does, which, unsurprisingly is allowed by an extremely catholic conformance clause" ?

    Or "conform to parts of standards you fancy using but feel free to mix in a bit of undefined, proprietary cruft if you like"

    Beware, it sounds like you’re giving Microsoft a free rein to go back to the bad old days!

    Gareth

  9. Rob Weir says:

    Gareth, I mean that if a standard permits a dimension of variability, then once should take one’s head out of one’s ass and look around at other products in the market, and if the preponderance of existing implementations are already following a formula convention that is conformant with the standard, then interoperability will be greater if one also follows that same convention rather then diverging onto a non-interoperable convention.  This is especially true if that convention is already undergoing standardization in a committee of which you are a member.

    This is so obvious that you almost need to be in the habit of beating yourself on the head with a hammer to not understand this.  

  10. Rob,

    I understand the pragmatic nature of this, of course, but aren’t "conventions" what we are trying to avoid?

    If everyone gets too comfortable with these conventions, then it could lead to OpenFormula being redundant, with the all-too-common slide down to the simplest lowest common denominator by vendors outside the "boxing ring".

    In any case, Microsoft have to be more careful than most with their approach to standards, you might have noticed.

    As Doug said, the philosophy and guidance on the implementation was known well in advance.  Perhaps a formal request and a pass for using "conventions" instead of standards from the ODF / OOO good and the great might have enabled them to do so without fear being accused of any wrongdoing.

    Conventions of a canonical app (Office) have been deemed very bad, historically.  Equitably, conventions of a canonical app (OpenOffice) must be seen in the same light.

    However, the world still turns happily, as the vendor who created the conventions (Sun) has created a plug-in which works with Microsoft Office to perpetuate these conventions in documents produced and consumed by Microsoft Office.  

    Everyone is happy.  Now if Microsoft had made it so the plug-in would not work, giving an error message with some heavy threats about standards etc etc, then we could rightfully be up in arms.

    We still have the choice, don’t we?

    Gareth

  11. Rob Weir says:

    Gareth, read my words more carefully.  I never said to not use the standard, or to use conventions instead of the standard.  I said to use common conventions to supplement the standard where needed to provide interoperability.  And this particular convention, although it may be in the OO XML namespace, is hardly an OO-specific convention.  As my tests showed, this convention is supported by every other ODF spreadsheet editor I tested, except for SP2.  So you cannot just explain it away by saying it is OO-specific.  Perhaps it originated in OO years ago. But everyone, even Microsoft’s own ODF Add-in for Excel, supports that convention.  But not SP2 for reasons that have still not been explained.

  12. Doug Mahugh says:

    But Rob, couldn’t that same argument be used to make a case for everyone sticking with the binary Office formats?  They were widely supported years ago, and continue to be.  And more to the point, couldn’t that same line of reasoning have been used by the ODF TC a few years ago to conclude that ODF should include formula syntax compatible with the millions of documents that already existed at that time with formulas in them?

    Regarding your desire for an explanation for our decision to not support the formula syntax used by OO, perhaps you missed this paragraph above:

    In Office’s implementation, we haven’t chosen to support the draft Open Formula spec (as Open Office currently does), because we have certain obligations when we ship software that don’t apply to open-source projects like Open Office.  We need to test and verify behavior to a degree that’s not possible without final, fixed documentation that is believed to be 100% complete and accurate.  When Open Formula is completed, standardized, and published, we’ll be looking at that as the future path for enabling formula interoperability in ODF spreadsheets.  But we’re not there yet; ODF 1.2 is not done, and not even ready for public review.

  13. Rob Weir says:

    Doug, the analogy would be this:  If we supported the legacy Office binary spreadsheet format, as do all spreadsheet applications that I know of, then we would look to the available specification, which Microsoft resurfaced last February after a decade’s absence.  But when we look in that binary format specification we find that has no coverage of spreadsheet formulas.  Zero. Zip.  Nada.  So what should we do?  Indeed, what did we and every other vendor do in that situation?  We looked around, found what the prevailing convention was and coded to it.

    You seem to be arguing that in that situation each vendor implementing the legacy binary format should make their own choice as to formula language and create non-interoperable documents.  Does that really make sense for the customer?   Certainly move the convention into a standard.  That is what a convention is in the end — a formalized convention.  But to replace an widely held convention and an emerging standard in a committee which you are a member of, with a divergent approach that is non-interoperable with any other vendors and indeed not compatible with your own ODF Add-in’s documents, this defies reason.

  14. Doug Mahugh says:

    Well, our "divergent approach" as you call it is based on the one and only approved and published standard for formula markup that exists, as of today.

    If we’re going to write formulas, that seems to me a pretty logical approach.  And when there’s another published standard for formula markup, we’ll look at that option as well (as I said above).

  15. Rob,

    So as I understand it, when Microsoft add extensions to an existing standard, as OOO does with formulas on top of ODF, it is called "Embrace, extend and extinguish" and is the vilest evil to ever have been visted on the earth, but when it’s not Microsoft, they are merely "conventions" which should be supported by all other vendors in an ecosystem.

    See "The Strategy" section in: http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

    Squirm in the irony of this when applied to OpenOffice + ODF.

    I know this is expressed in a rather emotive way, but purely to illustrate the point.

    One could say that one man’s evil extensions are another man’s conventions.

    Of course I read your words carefully, and my response reflected that.  I said standards + cruft, not cruft without any standards.

    As I said before, maybe this is a harsh implementation, but this is the post-EU-slapdown Microsoft, they have to be wary.  They don’t want to be accused of being complicit in EEE by proxy for OpenOffice 😉

    And again, you can still use the Sun plug-in.  They are the originators of said extension!

    Another thing – any response to my first question?

    "So I suppose the only difference is that the defaults are different in 1.3 😉  If that’s really the only difference then I think we are all allowed a bit of a laugh at your outrage.  I hope there is a bit more to it than that.  A quick overview of the 1.2-1.3 changes that explain the new behavior would be good."

    Gareth

  16. Jomar Silva says:

    Hi Dough,

    It’s funny to see your point: numbers only = data preserved (I bet that several economists will disagree with you, but ok).

    No additional comments 🙂

    Best,

    Jomar

  17. Matthew Raymond says:

    dmahugh: "Well, our "divergent approach" as you call it is based on the one and only approved and published standard for formula markup that exists, as of today."

    Irrelevant for the following reasons:

    1) The OOXML formula language was not approved and published as a separate standard. Rather it is part of a larger specification. Thus, it was not approved as a general purpose formula language. It was approved as part of a larger specification.

    2) The OOXML formulas do not match the syntax of the formula examples given in ODF 1.1 subsection 8.1.3. For instance, they exclude the brackets around the cell references. Thus the OOXML formula language is not in keeping with the spirit of the ODF 1.1 specification.

    3) The OOXML formulas violate ODF 1.1 subsection 8.3.1 by failing to include a dot before the cell reference.

    4) OOXML formulas are not a standard, defacto or otherwise, for other ODF 1.1 implementations.

    From the main article: "Open Office, for reasons I don’t understand, has decided to use as their default formula syntax the unfinished Open Formula specification, which is neither approved nor published by OASIS – not even out for public review yet."

    I beg to differ:

    http://www.oasis-open.org/committees/documents.php?wg_abbrev=office-formula

    Latest draft is less than a week old. That’s not public enough for you?

  18. Rob Weir says:

    Gareth, this is not the time or place to announce the exciting new features in Lotus Symphony 1.3  You’ll want to keep posted to http://symphony.lotus.com for that information.

  19. Luc Bollen says:

    @Dough, "Well, our "divergent approach" as you call it is based on the one and only approved and published standard for formula markup that exists, as of today."

    Well there is at least a big issue with this approach: the "approved and published standard for formula markup that exists" is NOT conformant with ODF 1.1 (there is no "." in front of the cell references).  So the OOXML formula syntax is NOT a possible choice if you want to respect the ODF standard.

    You can argue as long as you want, it is clear to everybody (even to you if you want to be honest) that this is again a trick used by Microsoft to break interoperability.

    But Microsoft making promises and not following them is no news: "the Commission notes that today’s announcement follows at least four similar statements by Microsoft in the past on the importance of interoperability" http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/08/106

    @Gareth, "this is the post-EU-slapdown Microsoft, they have to be wary."

    Well, Microsoft should be more wary then: "In its ongoing antitrust investigation concerning interoperability with Microsoft Office, the Commission will investigate whether the announced support of ODF (OpenDocument format) in Office leads to better interoperability and allows consumers to process and exchange their documents with the software product of their choice." http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/08/324

    This is clearly a very bad start…

  20. Luc Bollen says:

    @Doug, let’s have a closer look at your "Guiding Principles":

    * Adhere to the ODF 1.1 Standard: Failed.  The formula syntax used in SP2 does not adhere to ODF 1.1

    * Be Predictable: OK. You summarise this as "The principle here is that we want to do what an informed user would likely expect. "  Indeed, a user informed of Microsoft usage would likely expect that you find a trick to break interoperability.

    * Preserve User Intent: Failed.  The obvious intent of the user is to use formula, not to silently have them erased.

    * Preserve Editability: Failed.  As the formula are gone, you can no longer edit the file successfully.

    * Preserve Visual Fidelity: OK.

    I would say this is not a bright score…

  21. @Luc so you feel that the EU should deem extensions not included in a standard as a positive interoperability initiative that is to be (or forced to be?) supported in this case, but not say in Java or any other examples of EEE.

    One can’t bang on about interoperability with extensions now, when it has been decided that standards are the cure. Is interoperability the most important issue, or is it standards? Maybe a few vendors could get together in a smoky room and thrash out interoperability behind the scenes instead, would that be better?

    I don’t think the EU would base a legal challenge on this type of non-equitable basis.

    Microsoft have been supportive of implementing any future, published standard in this area, so the point is moot.  

    The press release contains 2 key concepts: ODF (no formulas, so irrelevant w.r.t the standard) & better interoperability.  

    There is now native support, rather than just the old MS-sponsored plug-in.  Whether it is better or not, I don’t personally know, but there has certainly been a considerable effort in terms of the code and implementation notes.  

    I imagine that over a wide range of scenarios (excepting the ones targeted to raise the temperature) the interoperability is better.  

    I guess only real customers with no agenda will be the only ones to be able to verify that.

    @Rob I am sure they will be beavering away at some features inspired by this very thread as we speak 😉

    Gareth

  22. Luc Bollen says:

    @Gareth: the role of the EC here is not to validate conformance to whatever standards.  It is to check if there is an abuse of a monopoly position that harms customers.  The EC press release don’t talk about standards.  It talks about "better interoperability" and allowing consumers "to process and exchange their documents with the software product of their choice". And SP2 offers worse interoperability than the previous CleverAge plug-in, not better.  Conclude yourself.

    It is easy to see, even for the EC, that the recent claims of Microsoft to be the White Knight defending the sacred Standards against the Evil OpenOffice and its Dark Lord Rob Weir is purely an hypocritical position, resulting is less interoperability rather than more interoperability.

  23. Stefan Gustavson says:

    Doug, we all understand you are deeply troubled by the failure of your employer to meet the expectations on a product update that is an exact match with your job title "Office Interoperability".

    However, I don’t think it is a great idea to try and save face by telling lies and trying to pretend that nothing bad happened. Nothing you say can cover up the very obvious facts:

    1) Excel 2007 does not produce conformant ODF 1.1 documents. (Small but important issues with missing brackets and the leading dot.) That is not interoperability.

    2) Excel 2007 won’t open any ODF 1.1 spreadsheet created by any other ODF-supporting software without silently crippling it by deleting all formulas. That is not interoperability.

    3) No other ODF 1.1 spreadsheet application will open an (almost-conformant) ODF 1.1 spreadsheet saved from Excel 2007. That is not interoperability.

    The actual product release certainly does not adhere to your own guidelines which you are quoting:

    "Adhere to the ODF 1.1 Standard", "Be Predictable", "Preserve User Intent", "Preserve Editability"

    and "Preserve Visual Fidelity". You need to admit that SP2 failed on at least three of five accounts here. (Deleting all formulas is bad but formally predictable behavior, and visual fidelity is preserved even by just importing a static table.)

    Excel 2007 is not interoperable through the ODF format, and does not yet deliver on your promises. Admit that, and maybe we can get on with fixing it instead of squabbling over why who did what. If you stay on your current path of denial, you will send the message that your job is not in fact "Office Interoperability", but something rather less honorable.

  24. Doug Mahugh says:

    The cell-reference issue that some of you have brought up is part of the broader issue of formula syntax in ODF.  We believe we are completely conformant with the spec on this matter, and that we have implemented formulas in a way that is consistent with the intent and spirit of the ODF specification.  I’ll post a blog post on this topic next, since I think it deserves more thorough and specific explanation than a comment box can contain.  (As Fermat put it, "Cuius rei demonstrationem mirabilem sane detexi. Hanc marginis exiguitas non caperet.")

    I must admit, it’s pretty fascinating to me to see the level of interest people have in discussing something (formulas) that doesn’t even appear in the ODF specification at all.  Imagine how much fun we’ll have when we start discussing things that are actually there!

  25. fmerletti says:

    "Imagine how much fun we’ll have when we start discussing things that are actually there!"

    this is the problem here, you are arguing with a guy who has "fun" with standards. Standards are a serious thing, not a game nor a Public Relations statement.

  26. Doug Mahugh says:

    But, but, but … you guys are making my head asplode!

    If standards are so serious, why are all of these people arguing that we should support things like OO.o’s historical formula syntax (never was a standard, never will be) or Open Formula (not yet a standard, probably will be eventually)?

    Which is it?  Do you think standards important, or not?

    In either case, here at Microsoft, we feel standards are important.  And we have fun, too.

  27. Luc Bollen says:

    Doug, if you are not convinced by Rob, please have a look at what the implementers of the add-in translator sponsored by Microsoft are saying:

    "In its first versions, the OpenXML/ODF translator simply did not translate formulas at all. Only the static values were preserved. Unfortunately, users are not really interested in what is part of a standard and what not. They actually want to get a good translation which means the preservation of all visual content and even of the functional content such as formulas. Consequently, we (the OpenXML/ODF Translator team of Sonata, DIaLOGIKa and Microsoft) decided to implement a decent formula translation approach in version 2.5 after having received a number of complains."

    http://odf-converter.sourceforge.net/newblog/index.php?2009/03/13/28-how-the-openxml-odf-translator-deals-with-formulas

    So, Microsoft already supports OO.o’s historical formula syntax, despite the fact that it never was a standard, and never will be.

    Can you explain this:

    – Microsoft first made an attempt at not supporting the OOo formula syntax, received complaints and "decided to implement a decent formula translation approach" in the translator;

    – at the same time, Microsoft decides that it is against the Microsoft serious approach to standards to support the same decent approach for SP2.

    This hypocrisy is so blatant that I would like to thank you for showing to the world and to the European Commission that there is no "new Microsoft", and that you remain the same monopoly abuser playing dirty tricks to avoid interoperability at all cost.

  28. gk says:

    Hi all,

      I do seem to see a higher degree of conformance required by microsoft by others. If its not in the spec, it is not advisable to implement it.

    Let me take a case… why don’t all browser manufacturers mimic internet explorer 6 to give practical interoperability.. This is because it is not the standard.

    Now u want microsoft to provide practical interoperability with ODF even though its not in the spec.???.. Seems pretty one sided to me..

  29. Luc Bollen says:

    @gk: "Now u want microsoft to provide practical interoperability with ODF"

    Microsoft itself committed to this practical, real world interoperability in its press release on 21-May-08: "Microsoft recognizes that customers care most about real-world interoperability in the marketplace, so the company is committed to continuing to engage the IT community to achieve that goal when it comes to document format standards." http://www.microsoft.com/Presspass/press/2008/may08/05-21ExpandedFormatsPR.mspx

    Many customers and ODF supporters *asked* for support of ODF in MS Office.  Nobody *forced* Microsoft to support ODF.  But if MS decides to provide support, it seems logical to require a working support, not a broken one aimed at fragmenting the corpus of ODF documents.

    What we see here is the same old tricks already used to fragment Java and HTML, for which MS has been punished respectively by an US court and the European Commission.

    I have no doubt that once again Microsoft will be punished by the EC for their current monopoly abuser behaviour.

  30. Rene says:

    @Luc

    Allthough the OpenXML/ODF translator was funded by Microsoft it is OSS software created by 3rd pary software producers and as such not belonging to any Microsoft software prodcut and I think it is safe to asume that Microsoft will not add OSS software snippets to their core software product as that would create possible license issues especially if someone were to reuse some GPL code in those sources.

  31. Doug Mahugh says:

    Luc, as I said in my post we have certain obligations when we ship software that don’t apply to open-source projects.  I’ll cover some more details of this in my follow-up post on spreadsheet interoperability coming shortly.

  32. Matthew Raymond says:

    Luc: "…I think it is safe to [assume] that Microsoft will not add OSS software snippets to their core software product as that would create possible license issues especially if someone were to reuse some GPL code in those sources."

      You can’t legally put GPL code into BSD at all, unless you’re the author, in which case you’d probably be required to relicense the code under BSD in order to submit it to the project in the first place.

      I think the whole issue of code reuse is beside the point, though. Microsoft has more than adequate resources to create whatever code they wish, especially when the development effort is directly associated with one of its primary sources of income: Microsoft Office. Of all parties involved, they are in the worst position to argue for choosing a formula language based on scarcity of resources.

  33. carlos says:

    doug, let me copy a snip of "code" from Weir’s blog:

    "So, going back to my test spreadsheets from all of the various ODF applications, how do these applications encode formulas with cell addresses:

       * Symphony 1.3: =[.E12]+[.C13]-[.D13]

       * Microsoft/CleverAge 3.0: =[.E12]+[.C13]-[.D13]

       * KSpread 1.6.3: =[.E12]+[.C13]-[.D13]

       * Google Spreadsheets: =[.E12]+[.C13]-[.D13]

       * OpenOffice 3.01: =[.E12]+[.C13]-[.D13]

       * Sun Plugin 3.0: [.E12]+[.C13]-[.D13]

       * Excel 2007 SP2: =E12+C13-D13

    "

    I would like to know why Excel 2007 doesn’t produce ODF 1.1 conformant documents, regarding this "cell address" thing.

    Thank you

  34. clippy says:

    carlos, a small correction:

    * OOo 3.0.1: of:=E12+C13-D13

    * Excel 2007 SP2: msoxl:=E12+C13-D13

  35. fmerletti says:

    clippy, actually

    * OOo 3.0.1: "of:=[.C4]+[.D4]+[.E4]"

    isn’t it?  

  36. Matthew Raymond says:

    @Clippy, carlos had it right the first time. In the Maya spreadsheet Rob Weir saved using OOo 3.0.1, the formula is "of:=[.E12]+[.C13]-[.D13]". This is a direct cut and paste.

    @carlos, Microsoft interprets the word "Typically" in section 8.1.3 as being infectious and recursive, converting everything it touches into non-normative examples. Thus, the content that a formula, cell addresses, and even all of section 8.3.1 become non-normative simply by being within seven degrees of the word "Typically". Never mind the fact that the specification makes perfect sense if you interpret "Typically" as only applying to having a equal sign at the beginning of the formula, as this example in 6.5.3 would indicate:

    text:formula=’ooo-w:[address book file.address.FIRSTNAME] == "Julie"’

    Note the use of the brackets used for addressing are present, but the preceding equal sign is missing.

    Microsoft’s interpretation of the ODF 1.1 specification is not necessarily a deliberate misreading, but even giving them that benefit of the doubt, they still ignored parts of the spec they considered informative to use the formula language that suited their interests rather than picking a widely used defacto standard that takes 8.1.3 and 8.3.1 to heart and promotes interoperability. The whole point of standards is to allow interchange. Anything else is just a subversion of the process.

  37. Doug Mahugh says:

    Matthew, there’s a long history how standards text is written and what’s normative or not; ISO and other standards bodies have rules governing such details as well.  I think it’s in everyone’s interest for us to follow those precedents and rules, rather than making up new rationales for such things.  The entire reason such rules exist is so that we DON’T get into these little debates about things like "what the meaning of the word ‘is’ is."

    As I’ve mentioned, I’ll cover all of this in my next blog post.  This discussion needs more facts and fewer opinions … in my opinion. 🙂

  38. Luc Bollen says:

    @Mathew: "The whole point of standards is to allow interchange. Anything else is just a subversion of the process."

    The pity is that subversion of processes is a standard at Microsoft  🙁

  39. hAl says:

    @Carlos

    The reason for several applications using the same cell referencing system is that this is used by OOo and that these applications implemented the existing OOo spreadsheet variation in ODF whereas MS has been  implementing the existing Excel spreadsheet variation in ODF and is using the cell referencing mechanism that Excel is using.

    It seems that the ODF 1.1 specification does not define normative specifications on how to reference spreadsheet cell or in fact anything normative about specifying spreadsheet content in an ODF spreadsheet.

  40. carlos says:

    thanks hAl

    doug, is that true?

    IMHO if it is, then this decision is totally inexcusable.

  41. A Nonymous says:

    @Doug Mahugh:

    If there is no standard (yet) for formulas in ODF, i.e. not specified in ODF 1.1 and not published or finalized in ODF 1.2… then why do anything with formulas at all?

    Why do SP2, period?

    Or, if you prefer, if you wanted to do something useful, consider the document base.

    How many ODF documents exist, world-wide? How does that compare to the empty set of documents in "ODF" format produced by SP2 (before there was an SP2)?

    This is a _document_ format issue, not an _application_ issue. It doesn’t matter as much how many installed versions of Vendor X software that read/write ODF – it matters how many of what "format" exist.

    So, why not take the approach of, "How do we build an SP that allows us to read the existing ODF files, and write them out again, so that the original author’s software could open the result?"

    I don’t think it is something a rocket scientist needs to suggest, at a DII meeting.

    Don’t forget, too, that the OOo source was and is available for reference in implementing SP2. I suggest the path of least resistance in the marketplace, would have been interoperating regardless of the state of standards — if you wanted to achieve any degree of interoperability.

    Name Withheld

  42. בימים האחרונים שוחררה חבילת השירות השניה של Office 2007. אחת התכונות הבולטות של חבילת השירות הזאת היא

  43. Reece says:

    @gk: "Let me take a case… why don’t all browser manufacturers mimic internet explorer 6 to give practical interoperability.. This is because it is not the standard."

    IE6 implements the HTML and CSS specifications. It simply does not conform to those standards. From what I can tell, Office 2007 SP2 can read/write ODF1.1 documents as specified.

    What is in question here is that the formulas are not specified in the current standard, but *are* being standardised in a separate formula standard that is being drafted and agreed upon that is ratifying what existing implementations and existing documents do. Where existing implementations – such as Symphony – do not conform at the moment, upcoming versions do to make them interoperable.

    I find it amusing that here Microsoft are saying "we can’t do XYZ as it is not standardised, and is still in draft" whereas the upcoming Visual Studio 10 is supporting language features in the draft C++0x standard!

    It seems that Microsoft is suffering from split-personality disorder and is choosing which standards and draft standards to conform to that best suite Microsoft. Like IE being one of the few vendors that don’t support Scalable Vector Graphics or MathML, instead going for a butchered hybrid that no-one else supports.

  44. Since Rob Weir moderates really nicely his blog, I assume he won’t post my question there.

    Rob, please tell me, what are today’s incentives given by IBM to it workers to hawk agendas?

    The following is just a precedent established by IBM:

    **********

    IBM Is Offering Workers Prizes to Hawk OS/2

    Paul B. Carroll, Staff Reporter

    The Wall Street Journal

    March 27, 1992

    International Business Machines Corp.’s sales force is already bigger than many armies, but as IBM prepares to start shipping its much-maligned OS/2 operating system, it has decided it needs reinforcements.

    So IBM is about to launch a program that will attempt to turn all its 344,000 employees into salesmen for the personal-computer software, which is in a fight for its life against Microsoft Corp.’s Windows juggernaut.

    IBM will offer employees incentives ranging from medals to IBM software or hardware to cash, depending on how much effort they put into OS/2. In return, says Lucy Baney, an IBM marketing executive, the company will ask employees to approach their neighbors, their dentists, their schoolboards. Armed with brochures and talking points, the IBMers will sing the praises of OS/2 as the solution to people’s personal-computing needs.

    IBM is pulling out most of the stops in advertising and pricing, too, as it prepares for one of the stiffest marketing battles the personal-computer industry has seen. IBM must not only overcome Microsoft’s considerable momentum but must also face a Microsoft marketing effort that, while very different and more low-key, is just as intense in support of Microsoft’s latest version of Windows. In fact, the situation here is the reverse of the one IBM normally sees; Microsoft is the entrenched power and IBM the struggling competitor attempting to dislodge it.

    "There’s a very serious commitment to energize the whole company behind the product," says Fernand Sarrat, the top OS/2 marketing executive.

    Although he declines to be specific on IBM’s advertising plans, he says that "there isn’t an IBM U.S. ad campaign that will receive anywhere near the dollars that OS/2 does" this year. That easily puts OS/2 advertising spending into the tens of millions of dollars, not counting the money IBM will spend on extensive international ads.

    Mr. Sarrat says the campaign will be informational rather than the sort of macho advertising that has been rumored in the trade press; one slogan that was reportedly considered was "Curtains for Windows." But Mr. Sarrat adds: "It’s not that we’ll be namby-pamby. That’s for damn sure."

    The campaign will really start rolling next month. IBM’s new version of OS/2 will be available to corporate customers next week, meeting IBM’s commitment to deliver it by the end of March, but it won’t be widely available in retail outlets until the second half of April. So even though Microsoft has already begun its campaign, in advance of its April 6 introduction of Windows 3.1, Mr. Sarrat says IBM has decided to wait a bit.

    On pricing, he says that people who have the latest version of OS/2 will get the new version free. Many users of Microsoft’s Windows and DOS will also get huge discounts off the list price of $195, but Mr. Sarrat declines to be specific, lest he tip his hand to Microsoft. (Windows 3.1 will have a list price of $150.)

    IBM’s pricing plan means it will be taking losses on many of its initial OS/2 sales. Software securities analysts have estimated that IBM must pay Microsoft a royalty of about $20 on each copy of OS/2, because it contains Windows software. They have said it also costs $30 or more to produce each copy of OS/2. And those figures don’t include any of IBM’s marketing expenses, any of the corporate overhead that eats up more than 30% of IBM’s revenue or any of the OS/2 development expenses that have totaled hundreds of millions of dollars.

    "This is a long-term war," Mr. Sarrat says.

    He predicts that IBM will sell millions of copies of OS/2 this year, even though it has sold something less than one million copies in the five years since OS/2’s introduction. Mr. Sarrat even goes so far as to predict that within a few years OS/2 will be outselling Windows, which Rick Sherlund, a securities analyst at Goldman Sachs, predicts will sell 11 million to 12 million copies in the fiscal year ending June 30 and 17 million copies the following year.

    "It won’t happen this year or next year," Mr. Sarrat says, "but after next year it’s fair game."

    In contrast to IBM, Microsoft will spend most of its effort "making sure people have a good experience" with its new version of Windows, says Steve Ballmer, a Microsoft executive vice president.

    Microsoft will spend plenty of money on advertising, including its first television campaign. Mr. Ballmer says a published estimate of a $31 million marketing effort "is probably low even as a U.S. number." Microsoft will also be aggressive on pricing, offering upgrades to the new version for $50 initially.

    But Mr. Ballmer says most of Microsoft’s effort will go into a huge program to train computer dealers, to offer workshops to heavy Windows users and to help people get information on how to use the product. Patty Stonesifer, a Microsoft vice president in charge of customer support, says that Microsoft has 500 people available to answer telephone callers’ questions on Windows, up from 70 when the prior version of Windows came out in May 1990. She says Microsoft has also invested heavily in an electronic bulletin board to keep users up to date on problems that surface with the software and to provide the latest tips on how to use Windows better.

    "Making Windows easier to use will be a demand generator in itself," she says.

    Microsoft has also mounted an aggressive public-relations campaign in recent weeks, having executives do waves of interviews to address OS/2. The executives have argued, in particular, that while OS/2 may make sense for IBM’s traditional corporate users, it is too complex and requires too much memory to attract the broad mass of users who have been drawn to Windows.

    Still, Mr. Ballmer acknowledges that many people in the computer industry and many users "are rooting for some healthy competition. People want a healthy, knockdown, drag-out fight. But we haven’t shipped, and IBM hasn’t shipped. In the next few weeks, we’ll see what happens."

    Copyright Dow Jones & Company Inc

  45. Rick Jelliffe says:

    I think there are actually two issues.

    One is what is the most appropriate format for Office SP2 to save, in the interim new world of strongly-labelled formulas before Open Formula is released. The other is what formats Office SP2 should load successfully, in the interim new world of strongly-labelled formulas before Open Formula is released.

    The ODF spec clearly says that the namespace prefix can select the syntax. I don’t have much problem with Microsoft exporting in Excel with a proper label, as the implementation notes say; it is up to other importing applications to add filters to get interoperability. The lag is just a ramification of the ODF 1.1 spec.

    But what is good for the goose has to be good for the gander. For load, the current approach in SP2 and the implementation notes is clearly deficient for interoperability. Instead of failing if the syntax is not Excel, trying it in the dot notation would be genuine interoperability.  

    This is nothing more than Postel’s law: being conservative in what you send and generous in what you receive, which has proved itself a pretty good mindset for implementers.  

  46. Rob Weir says:

    You’re asking me about OS/2?!?  I was still at Harvard when OS/2 was being marketed.  You’ll need to ask someone much older than me about that.

    To Doug’s point on "typically", the question is when does the scope of that word end?  I suggest that it ends when the verbal phrase ends.  This is standard English usage.  Anyone is welcome to suggest an alternative reading, but you will need to state where the effect "typically" ends, and on what principle you make that reading.  Simply throwing your hands up and saying ,"Oh my, this doesn’t follow ISO drafting guidelines for the preparation of standards, therefor it means anything I want, or maybe nothing at all, based on my whim" — that doesn’t cut it.  You need to state your principles and interpret the text that you have, not the text that you wish you had.

  47. Thank you Doug.

    I don’t expect Rob to answer my question.

    Nonetheless, another question arises, has IBM extended the above incentives to publications such as Groklaw?

    One fact that intrigues me is all the fuzz about document standards knowing Linux market share on the desktop at 1% unchanged during the past 8 years:

    http://tinyurl.com/d4rk4j

    and

    http://tinyurl.com/6myem6

    The second fact that intrigues about all the fuzz on standards is the lack of a word processor and spreadsheet equivalent to MS Word and MS Excel in the Linux world until pretty recently:

    http://tinyurl.com/pv2w6w

    The last fact the intrigues me is the lack of good GUIs in the Linux world (which have ‘borrowed’ a lot from MS Windows) until only a few years ago:

    http://tinyurl.com/ode57y

    Why all of the sudden so much fuzz for document standards?

  48. Rob, a key paragraph is:

    "IBM will offer employees incentives ranging from medals to IBM software or hardware to cash, depending on how much effort they put into OS/2. In return, says Lucy Baney, an IBM marketing executive, the company will ask employees to approach their neighbors, their dentists, their schoolboards. Armed with brochures and talking points, the IBMers will sing the praises of OS/2 as the solution to people’s personal-computing needs."

    Let me refrase the paragraph for you:

    IBM will offer employees incentives ranging from medals to IBM software or hardware to cash, depending on how much effort they put into ODF. In return, says an IBM marketing executive, the company will ask employees to approach their neighbors, their dentists, their schoolboards. Armed with brochures and talking points, the IBMers will sing the praises of ODF as the solution to people’s document needs.

  49. marc says:

    I tried the formula-thing in Gnumeric creating and saving a simple spreadsheet. The result: Gnumeric saves formulas in the interoperable way ( contrary to what the Microsoft product does ):

    "oooc:=[.B3]+[.C3]+[.D3]"

    ~ $ gnumeric –version

    gnumeric version ‘1.8.2’

  50. oiaohm says:

    Does the world reference implementation slip out side your minds.

    How do you think bugs are going to be found in the new draft standard for formulator if its not implemented.

    OpenOffice is the reference implementation so they do items from draft.   Still provide option to save in prior format.

    I am sorry but openoffice’s  formula syntax is documented for all versions even the old Staroffice file formats style is documented.  OpenOffice changed over to the draft standard because it would be more future safe.

    Yes gnumeric koffice IBM Lotus Symphony and others have managed to operate in a compatible way.  OpenOffice syntax 1 of them.

    MS choose to be incompatible so be it.

    Correct Openoffice’s spreedsheet formal are not compatible with Excels .  Openoffice don’t have rounding errors and has more functions.  Excel support is a small subset.   So excel is still short many functions to do 1.2 support when it gets released.

  51. Doug Mahugh and a bunch of the standards crew (both in and out of Microsoft) have been having a great

  52. ghomem says:

    I wrote a comment here that was moderated. Thank you.

  53. Doug Mahugh says:

    ghomen, I just looked through the comment table and I don’t see anything from you that hasn’t been let through.  Can you tell me the rough date/time?  Or re-post?  Thanks.

  54. ghomem says:

    @dmahugh

    My comment was:

    You are trying to justify a major fault on Microsoft’s ODF implementation with problems on a very specific and unuseful scenario (summing strings!). That scenario hardly matters at all when compared to the state of interoperability you left ODF with.

    I sincerely think that there’s no possible excuse for what was done given so many existing reference implementations (including your own supported plugin).

    Probably it’s not up to you to decide, but this really looks like a trick to spread FUD on ODF portability. People will notice, you know? There’s nothing that can be said to save face at this time.

    Can something be done?

    Suggestion: issue an urgent fix for this and get your credibility restored.

  55. Why the hell a lot of people is talking about a standard not yet approved (ODF 1.2)?

    Hey guys, I´m a Linux user (Debian), and I agree with Microsoft in this point of view.

    And… Why the hell OOo is using ODF 1.2?

    This is out of standard! Where is the interoperatibilty?

    Why the hell OOo don´t follow the ISO/IEC/Whatever 26300 (ODF 1.0/1.1)?

    If they follow ODF 1.2, so they are OUT of standard and interoperability!

    And… Come one, help me with this bug:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501996

    ehehehehhehe

    Regards,

    Renato S. Yamane

    Brazil

  56. Hi Doug,

    I have to say I am not a fan of Microsoft (to not say that I hate it), but no one has the rights to say anything against MS for the reason explained in your post (there are other reasons to not like the company where you work, but this one is not one of them).

    It makes me wonder, how could ODF 1.0/1.1 be approved as an ISO standard? The lack of specification on how to define formulae is just a joke.

    Let’s see if MS Office will follow the new ODF standard with this problem fixed when it is ready and aproved.

    Regards,

    Carlos

  57. Carl says:

    To all that say there are no standards for formulas. Did you actually _read_ Rob Weir’s blog post? I will copy the link for you: http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html

    Carefully pay attention to the quotes of section 8.1.3 and 8.3.1 of the ODF 1.1 standard. Then compare the entries for the different spreadsheet products and how they encode a formula. If you still do not see that Excel 2007 SP2 is the one that breaks the formal standard, then well, go on living in your universe….

  58. Doug Mahugh says:

    Carl, everyone is entitled to their own unique interpretation of the normative requirements of ODF 1.1, if they’re so inclined.  The interpretation you’ve linked to is one perspective, although it seems to be a perspective held by one member of the ODF TC and no others.

    Here are a few other opinions you may find interesting or helpful:

    From an ODF TC member and ODF implementer: http://ajg.math.concordia.ab.ca/?p=4

    From the convenor of SC34 WG1: http://adjb.net/post/Notes-on-Document-Conformance-and-Portability-4.aspx

    From a longtime document standards contributor: http://broadcast.oreilly.com/2009/05/odf-11-formula-support-in-office-sp2.html

    From the ODF editor: http://www.durusau.net/publications/whats_to_like.pdf

    It’s also worth noting that Excel 2007 SP2’s approach to formulas was publicly demonstrated last July (at an interoperability event that I invited all members of the ODF TC to attend).  So there’s no new  information here in nearly a year.  For a non-Microsoft perspective on the formula details that was posted last year, see here: http://idippedut.dk/post/2008/08/18/DII-ODF-workshop-the-good-stuff.aspx

  59. Un article de fond qui montre bien comment les problèmes d’interopérabilité sont complexes. http://blogs