Last year, when I was socializing the idea of creating the OASIS ODF Interoperability and Conformance TC, I gave a presentation I called “ODF Interoperability: The Price of Success”. The observation was that standards that fail never need to deal with interoperability. The creation of test suites, convening of multi-vendor interoperability workshops and plugfests is a sign of a successful standard, one which is implemented by many vendors, one which is adopted by many users, one which has vendor-neutral venues for testing implementations and iteratively refining the standard itself.
Failed standards don’t need to work on interoperability because failed standards are not implemented. Look around you. Where are the OOXML test suites? Where are the OOXML plugfests? Indeed, where are the OOXML implementations and adoptions? Microsoft Office has not implemented ISO/IEC 29500 “Office Open XML”, and neither has anyone else. In one of the great ironies, Microsoft’s escapades in ISO have left them clutching a handful of dust, while they scramble now to implement ODF correctly. This is reminiscent of their expensive and failed gamble on HD DVD on the XBox, followed eventually by a quick adoption of Blue-ray once it was clear which direction the market was going. That’s the way standards wars typically end in markets with strong network effects. They tend to end very quickly, with a single standard winning. Of course, the user wins in that situation as well. This isn’t Highlander. This is economic reality. This is how the world works.
Although this may appear messy to an outside observer, our current conversation on ODF interoperability is a good thing, and further proof, to use the words Microsoft’s National Technology Director, Stuart McKee, that “ODF has clearly won“.
Fixing interoperability defects is the price of success, and we’re paying that price now. The rewards will be well worth the cost.
We’ve come very far in only a few years. First we had to fight for even the idea and acceptance of open standards, in a world dominated by a RAND view of exclusionary standards created in smoke filled rooms, where vendors bargained about how many patents they could load up a standard with. We won that battle. Then we had to fight for ODF, a particular open standard, against a monopolist clinging to its vendor lock-in and control over the world’s documents. We won that battle. But our work doesn’t end here. We need to continue the fight, to ensure that users of document editors, you and I, get the full interoperability benefits of ODF. Other standards, like HTML, CSS, EcmaScript, etc., all went through this phase. Now it is our turn.
With an open standard, like ODF, I own my document. I choose what application I use to author that document. But when I send that document to you, or post it on my web site, I do so knowing that you have the same right to choose as I had, and you may choose to use a different application and a different platform than I used. That is the power of ODF.
Of course, the standard itself, the ink on the pages, does not accomplish this by itself. A standard is not a holy relic. I cannot take the ODF standard and touch it to your forehead say “Be thou now interoperable!” and have it happen. If a vendor wants to achieve interoperability, they need to read (and interpret) the standard with an eye to interoperability. They need to engage in testing with other implementations. And they need to talk to their users about their interoperability expectations. This is not just engineering. Interoperability is a way of doing business. If you are trying to achieve interoperability by locking yourself in a room with a standard, then you’ll have as much luck as trying to procreate while locked in a room with a book on human reproduction. Interoperability, like sex, is a social activity. If you’re doing it alone then you’re doing it wrong.
Standards are written documents — text — and as such they require interpretation. There are many schools of textual interpretation: legal, literary, historic, linguistic, etc. The most relevant one, from the perspective of a standard, is what is called “purposive” or “commercial” interpretation, commonly applied by judges to contracts. When interpreting a document using an purposive view, you look at the purpose, or intent, of a document in its full context, and interpret the text harmoniously with that intent. Since the purpose of a standard is to foster interoperability, any interpretation of the text of a standard which is used to argue in favor of, or in defense of, a non-interoperable implementation, has missed the mark. Not all interpretations are equal. Interpretations which are incongruous with the intent of standardization can easily be rejected.
Standards can not force a vendor to be interoperable. If a vendor wishes deliberately to withhold interoperability from the market, then they will always be able to do so, and, in most cases, devise an excuse using the text of the standard as a scapegoat.
Let’s work through a quick example, to show how this can happen.
OpenFormula is the part of ODF 1.2 that defines spreadsheet formulas. The current draft defines the addition operator as:
6.3.1 Infix Operator “+”
Summary: Add two numbers.
Syntax: Number Left + Number Right
Semantics: Adds numbers together.
I think most vendors would manage to make an interoperable implementation of this. But if you wanted to be incompatible, there are certainly ways to do so. For example, given the expression “1+1” I could return “42” and still claim to be interoperable. Why? Because the text says “adds numbers together”, but doesn’t explicitly say which numbers to add together. If you decided to add 1 and 41 together, you could claim to be conformant. OK, so let’s correct the text so it now reads:
6.3.1 Infix Operator “+”
Summary: Add two numbers.
Syntax: Number Left + Number Right
Semantics: Adds Left to Right.
So, this is bullet-proof now, right? Not really. If I want to, I can say that 1+1 =10, if I want to claim that my implementation works in base 2. We can fix that in the standard, giving us:
6.3.1 Infix Operator “+”
Summary: Add two numbers.
Syntax: Number Left + Number Right, both in base 10 representations
Returns: Number, in base 10
Semantics: Adds Left to Right.
Better, perhaps. But if I want I can still break compatibility. For example, I could say 1+1=0, and claim that my implementation rounds off to the nearest multiple of 5. Or I could say that 1+1 = 1, claiming that the ‘+’ sign was taken as representing the logical disjunction operator rather than arithmetic addition. Or I could do addition modulo 7, and say that the text did not explicitly forbid that. Or I could return the correct answer some times, but not other times, claiming that the standard did not say “always”. Or I could just insert a sleep(5000) statement in my code, and pause 5 seconds every time the an addition operation is performed, making a useless, but conformant implementation And so on, and so on.
The old adage holds, “It is impossible to make anything fool- proof because fools are so ingenious.” A standard cannot compel interoperability from those who want resist it. A standard is merely one tool, which when combined with others, like test suites and plugfests, facilitates groups of cooperating parties to achieve interoperability.
Now is the time to achieve interoperability among ODF implementations. We’re beyond kind words and empty promises. When Microsoft first announced, last May, that it would add ODF support to Office 2007 SP2, they did so with many fine words:
- “Microsoft Corp. is offering customers greater choice and more flexibility among document formats”
- Microsoft is “committed to work with others toward robust, consistent and interoperable implementations”
- Chris Capossela, senior vice president for the Microsoft Business Division: “We are committed to providing Office users with greater choice among document formats and enhanced interoperability between those formats and the applications that implement them”
- “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”
- Microsoft will “work with the Interoperability Executive Customer Council and other customers to identify the areas where document format interoperability matters most, and then collaborate with other vendors to achieve interoperability between their implementations of the formats that customers are using today. This work will continue to be carried out in the Interop Vendor Alliance, the Document Interoperability Initiative, and a range of other interoperability labs and collaborative venues.”
- “This work on document formats is only one aspect of how Microsoft is delivering choice, interoperability and innovative solutions to the marketplace.”
So the words are there, certainly. But what was delivered fell far, far short of what they promised. Excel 2007 SP2 strips out spreadsheet formulas when it reads ODF spreadsheets from every other vendor’s spreadsheets, and even from spreadsheets created by Microsoft’s own ODF Add-in for Excel. No other vendor does this. Spreadsheet formulas are the very essence of a spreadsheet. To fail to achieve this level of interoperability calls into question the value and relevance of what was touted as an impressive array of interoperability initiatives. What value is an Interoperability Executive Council, an Interop Vendor Alliance, a Document Interoperability Initiative, etc., if they were not able to motivate the most simple act: taking spreadsheet formula translation code that Microsoft already has (from the ODF Add-in for Office) and using it in SP2?
The pretty words have been shown to be hollow words. Microsoft has not enabled choice. Their implementation is not robust. They have, in effect, taken your ODF document, written by you by your choice in an interoperable format, with demonstrated interoperability among several implementations, and corrupted it, without your knowledge or consent.
There are no shortage of excuses from Redmond. If customers wanted excuses more than interoperability they would be quite pleased by Microsoft’s prolix effusions on this topic. The volume of text used to excuse their interoperability failure, exceeds, by an order of magnitude, the amount of code that would be required to fix the problem. The latest excuse is the paternalistic concern expressed by Doug Mahugh, saying that they are corrupting spreadsheets in order to protect the user. Using a contrived example, of a customer who tries to add cells containing text to those containing numbers, Doug observes that OpenOffice and Excel give different answers to the formula = 1+ “2”. Because all implementations do not give the same answer, Microsoft strips out formulas. Better to be the broken clock that reads the correct time twice a day, than to be unpredictable, or as Doug puts it:
If I move my spreadsheet from one application to another, and then discover I can’t recalculate it any longer, that is certainly disappointing. But the behavior is predictable: nothing recalculates, and no erroneous results are created.
But what if I move my spreadsheet and everything looks fine at first, and I can recalculate my totals, but only much later do I discover that the results are completely different than the results I got in the first application?
That will most definitely not be a predictable experience. And in actual fact, the unpredictable consequences of that sort of variation in spreadsheet behavior can be very consequential for some users. Our customers expect and require accurate, predictable results, and so do we. That’s why we put so much time, money and effort into working through these difficult issues.
This bears a close resemblance to what is sometimes called “Ben Tre Logic”, after the Vietnamese town whose demise was excused by a U.S. General with the argument, “It became necessary to destroy the village in order to save it.”
Doug’s argument may sound plausible at first glance. There is that scary “unpredictable consequences”. We can’t have any of that, can we? Civilization would fall, right? But what if I told you that the same error with the same spreadsheet formula occurs when you exchange spreadsheets in OOXML format between Excel and OpenOffice? Ditto for exchanging them in the binary XLS format. In reality, this difference in behavior has nothing to do with the format, ODF or OOXML or XLS. It is a property of the application. So, why is Microsoft not stripping out formulas when reading OOXML spreadsheet files? After all, they have exactly the same bug that Doug uses as the centerpiece of his argument for why formulas are stripped from ODF documents. Why is Microsoft not concerned with “unpredictable consequences” when using OOXML? Why do users seem not to require “accurate, predictable results” when using OOXML? Or to be blunt, why is Microsoft discriminating against their own paying customers who have chosen to use ODF rather than OOXML? How is this reconciled with Microsoft’s claim that they are delivering “choice, interoperability and innovative solutions to the marketplace”?
It seems both OpenOffice and Symphony do not produce valid ODF (your recents example files are actually invalid ODF) whereas MS Office 2007 and KOffice do produce valid ODF.
Before being interoperable would it be to much to ask for both long time ODF supporters IBM and Sun/OOo to produce valid ODF if even newcomer MS Office can do that.
Microsoft is playing the spec trick in that they won’t tell that in fact the precedents of adding two non-numeric literals is an effect of the run-time application (i.e. resolved at run-time by the calc engine which is the last piece of the proprietary chain ), not something that appears in the formula spec (which is simply a list of functions with explained meaning and parameters).
The problem with a file format that is so pervasive is that this creates a precedent no matter how wrong the addition of those two non-numeric literals is.
Interesting is given the giant mess that the handling of string is, given the locale spaghetti that Microsoft changes with almost every new version of MS Office (despite claiming compatibility, that goes without saying…), Microsoft won’t probably show any such example. That’d be a little bit embarassing.
– Stephane Rodriguez
@Andre, by all means implementations should be outputting valid ODF XML. But this isn’t a pre-req for interoperability, nor an excuse for not being interoperable. Validity and conformance are the relationship between an implementation and the standard. Interoperability is the relationship between the user and their documents and what they want to do with their documents. So conformance and interoperability operate in two different domains. Achieve both, by all means. But remember who pays the bills!
@Stephane, Good point. I did not bother to go into the fact that adding text and numbers is unpredictable, even in Excel, because of the locale dependencies. So the same formula, 1 + “1,234”, yields 1235 in the U.S. Excel, but 2.234 in German Excel, due to different interpretations of the comma, whether a decimal separator or thousands separator.
Matthew Raymond says
If I were a spreadsheet application vendor, I’d refuse to implement OOXML formula support for ODF. Although vendors probably have the necessary code already in their XLS file import code, there’s nothing stopping Microsoft from changing the OOXML formula language at a later date (probably in response to “ISO spec changes”) to create subtle incompatibilities. After all, if Microsoft can output using whatever formula language they want and still be “conformant”, what’s to stop them from using the Formula-Language-Of-The-Day?
Furthermore, vendors would still have to output using OpenOffice.org formulas to remain interoperable with the other vendors, so Microsoft would still silently drop formulas. All the while, users could still gain access to Microsoft-generated formulas in other vendor’s applications by simply removing the “msoxml:” prefix, which could probably be done with a simple macro.
Supporting OOXML formulas for ODF 1.1 makes sense for no one other than Microsoft.
“If I were a spreadsheet application vendor, I’d refuse to implement OOXML formula support for ODF.”
Vendors have no choice. They must expose both :
If Microsoft wanted to do well, all they had to do was save both formulas in the cell (and expose an advanced options in the Save dialog for those of us wary about the size of the file), making it conformant with existing ODF applications, compatible with their own read/write round-trip. After all, that’s just XML. They chose not to do so. The intention is very clear : ODF is a virus that must be stopped.
Luc Bollen says
@Stéphane: I think that vendors have a choice. If all the vendors boycott MSODF , the format will be useless and Microsoft will have either to drop it or to correct it to be interoperable with the other ODF implementations.
Of course, being useless might be the intent here. Didn’t the Germans in WWII hatch the plan of counterfeiting the British currency so they could air drop it over the UK to destabilize their economy? The same idea works with document formats. If you have the monopoly on silver coins, then you mint millions of fake gold coins.
“Doug’s argument may sound plausible at first glance. There is that scary “unpredictable consequences”. We can’t have any of that, can we? Civilization would fall, right?”
This is what my law professor told us students. Society depends on a social code. Litigation overkill would destroy a society.
Of the two Export that vendors have to support if they intend to support the files out there (customers will file them bugs if they don’t), it’s very unfortunate that serious vendors should support MS-ODF first since it has become the primary ODF generator overnight.
The irony is, since Microsoft only supports a tiny subset of of the file format, that should trigger a customer backlash. But the little they support, the round-trip scenario is OK, meaning there is a real intention to fragment ODF out there.
I do support ODF in my product, and I can only notice the level of support that Microsoft accomplishes is just two weeks worth of work (at my speed). I don’t understand it took them so much time to ship this.
“Before being interoperable would it be to much to ask for both long time ODF supporters IBM and Sun/OOo to produce valid ODF if even newcomer MS Office can do that.”
Are you arguing that it is OK for Office SP2 to silently destroy user’s spreadsheets? Just because there is another ODF application somewhere that might not implement ODF perfectly?
Conformance is no excuse to destroy user documents.
‘If a vendor wants…they need to…They need to…And they need to…’ No ‘they’ don’t. ‘He’ or ‘she’ does’.
Alternatively, if you are so pc that you do not wish to use the ‘he’ or ‘she’ words’, then it is perfectly acceptable to write: ‘If vendors want…they need to…They need to…And they need to…’
If the number of a relative pronoun does not agree with its antecedent, whatever assertion is being made is necessarily nonsensical.
Now, it is not difficult to adopt the correct procedure as I have demonstrated above. After all, if standards really matter, they matter in English.
Hmm, but lets say you have a wildly dominant market position, and not interoperating with other products will only harm their uptake? Why would you spend effort to help your competitors compete?
It’s pretty different from the internet, html or even hi-definition video. And even then we’re still all paying for corruption of internet standards.
Document formats on the other hand have a single dominant vendor with all the network effects on their side already. Interoperability based on the file format alone is not enough to force their hand or shift their position.
Maybe other things will help though. The GFC for instance, and simply having competing products that can’t be undercut, or bought, or put out of business.
Luc Bollen says
@Stéphane: “serious vendors should support MS-ODF first since it has become the primary ODF generator overnight.”
I beg to disagree. There have been millions of downloads of OOo 2.x and 3.x. How many downloads of MS Office 2007 SP2 ? Out of these, how many people using it to generate ODF files ? I bet this is a very small number, and will remain so for quite some time.
David Newkirk says
@ossianic, do have a look at a good modern dictionary–Merriam-Webster’s Collegiate, 11th ed, will do–about the modern use of they and their and similar words. Also take a look at the definition of the word synesis, regional tendencies and personal proclivities toward which can lead to seemingly superficial disagreement between noun and verb number. Also grok the difference between formal and informal writing; Rob’s converational style is fine. Attacking the speaker’s language when you know very well what he means is ad hominem attack, which we understand–with great sympathy–to mean that you are unable to refute him on the merits of his argument. Praise be that the CPU between our ears is more fault-tolerant than the processes of Mind it hosts.
“There have been millions of downloads of OOo 2.x and 3.x. “
Those couple millions pale compared to the MS Office install base (500+ million), and not to discount the power of distribution subsequent to that install base. My customer data shows that people out there install the latest service pack very fast. And by people I mean corporations of all sizes.
Don’t forget, everybody uses MS Office, so it’s already installed. If you need to download (subject to permission in the organization), install (permission) and use (permission) OpenOffice in order to view a .odf document, it won’t take long before people make it a habit to use MS Office and get used to the limitations and problems.
Let’s see, 6 month for now, where we are.
Luc Bollen says
@Stéphane: I agree with your explanation.
But as the 500+ million installed base covers all the version of Office, and as SP2 is usable only with the Office 2007 version, it will take some time for MS-ODF files to outnumber the other ODF files.
Six months is surely more realistic than overnight.
Luc Bollen says
@Stéphane: As the 500+ million installed base covers all the versions of Office, and as SP2 is usable only with the Office 2007 version, it will take some time for MS-ODF files to outnumber the other ODF files.
This being said, if MS is not stopped by a competition law regulator, it will likely happen (within six months being more realistic than overnight).
And it will be faster if all the other vendors play MS catch-up and support their currently non-interoperable MS-ODF files…
Once again, MS will have succeeded in fragmenting a competitive technology and pushing the interoperability burden to their competitors. Sad…
Carlos D'Fulvio says
“Interoperability, like sex, is a social activity. If you’re doing it alone then you’re doing it wrong.”I liked this phrase, it synthesizes a lot.
Regarding the recent fiasco about the-no-interoperable-way-of-Microsoft-implementing-ODF-support-in-Office-2007-SP2 perhaps we can say that Microsoft is an “onanist” in standard implementations?
Luc Bollen says
And of course, once all the competitors will have adapted their software to accept the “msoxl” namespace, Office 2007 SP2 will continue to silently drop the formulas from the ODF files produced by these competitors.
And Microsoft will claim that only OOXML files processed by Microsoft software is a safe approach… despite this being far from the truth, but which spin doctor would care ?
“We’ve come very far in only a few years. First we had to fight for even the idea and acceptance of open standards” IMHO, the mere fact of Microsoft at least “talking” about openness and interoperability is a *great* achievement.
The following links are fine to remember how was the scenery years ago:
. Bill gates memo about Office customer lock-in via undocumented proprietary extensions
. “Microsoft on standards” article –Orlando
A mechanism by which today’s ODF compatible applications can neutralize MS-ODF is by supporting it natively. It’s not very hard, since it’s Excel’s formula syntax, not a 3rd variant. Note that this applies to everything formula related (such as chart data sources), not only cell formulas. This should be a proprietary so that the user experience is smooth.
If OpenOffice and others directly support MS-ODF, silently and nicely (converting it to real ODF without the user knowing at every opportunity), it keeps afloat the investment in ODF. Otherwise, it’s highway for MS-ODF.
@Stephane, the practical problem is the first vendor who changes their formulas to match what MSFT has done will find themselves incompatible with all other vendors except for Microsoft.
Also, this would be diverging from OpenFormula. OpenFormula is very close to what the vendors are already writing out today in ODF applications. In fact, replace the namespace in the test documents I created and they would be perfectly correct OpenFormula formulas. The syntax in OpenFormula is not novel compared to what ODF vendors are alread doing. What is new in OpenFormula is a very detailed description of formal semantics.
If vendors move to the Excel-style encoding, it would be diverging from ODF 1.2 creating more junk for us to clean up later.
Luc Bollen says
“it would be diverging from ODF 1.2 creating more junk for us to clean up later.”
This is exactly what MS is hoping: create a mess that others will have to clean. This is the only way they are used to compete.
Doug and al. are hypocritical when they claim “we replaced an unspecified formula syntax by an ISO standard one”, knowing perfectly that
– the formula syntax in OOo is the same as the one in OpenFormula,
– the formula syntax in OOXML would have been rejected as a stand-alone standard by ISO, in the same way as VML was rejected; both became part of an “ISO standard” via the OOXML backdoor,
– the formula syntax in OOXML will sooner or later be replaced by OpenFormula, even in the MS products.
So replacing the OOo syntax by the Excel syntax, as easy as it can be, is moving backward rather than moving forward. And is creating a mess that everybody will have to clean and a legacy that will be floating around for a long time.
OASIS will win the standard ODF battle, in the same way as W3C won the standard HTML battle and Sun won the standard Java battle. But MS tries to postpone this as much as possible, by creating as much mess as possible to distract their competitors and waste their resources. It started with imposing everybody to debug their OOXML “specification”, then to write OOXML input filters, now to write MS-ODF input filters, and possibly MS-ODF output filters. What’s next ?
All these efforts are distracted from what should remain the community main goal: develop a good ODF standard and good ODF applications, and foster their usage.
@David Newkirk: ‘…do have a look at a good modern dictionary–Merriam-Webster’s Collegiate, 11th ed’
I have the complete Oxford English Dictionary on my computer.
Dictionaries merely record usage – whether such usage is accurate or not. If language is not used carefully, hostages are given to fortune – and frequently money is given to lawyers. Indeed, the whole SCO case (and the very existence of Groklaw) rests on such use and mis-use of language. The Microsoft OOXML/ISO shambles involves a very great deal of the same.
I repeat, if standards matter, they matter in English (or any other language used for communication).
@David Newkirk: ‘…you are unable to refute him on the merits of his argument’.
I am not trying to refute him. I agree with his argument. I am simply trying to point out ways in which he can strengthen it – and not undermine it by his own efforts.
The important thing is to make sure all the true ODF vendors don’t rush into a trap.
If the other ODF vendors start to load formulas from the ooxml namespace then the MS will be able to start dancing the “OpenFormula support will be added when at a later point because OpenFormula was designed after MS Office so we must change lots of unspecified code” and all the time postpone the date when they actually start being interoperable. You can not bargain with MS when you have given in.
Until MS start to load the formulas from all competetitors the ODF vendors must not start to load ooxml formulas.
The first correct step is probably that all ODF vendors start to output warnings when the ooxml namespace is encountered with information to the users that the document was created by MS Office that has modified the format used for it to be unable to be loaded and information about how to send bug reports to MS.
I was probably not clear enough.
When I said ODF-compatible applications should support MS-ODF natively, I meant during the file reading phase. So the updated applications can read both ODF and MS-ODF, encompassing everything out there.
Matthew Raymond says
@Stephane Rodriguez, I had similar thoughts on the matter, but what concerns me is that reading the files gives a false impression of interoperability where none exists.
Let’s say Institution Alpha has decided to standardize on ODF and tests to see if there programs can read MS-ODF files. The spreadsheet loads right up for all major vendors, and when they save from the other vendors and reopen in MS Office they don’t see any broken formulas, so Alpha decides to buy MS Office and standardize on it exclusively to reduce training and IT costs.
Later, a small company called Beta Incorporated is working with Alpha and receives an MS-ODF spreadsheet to make corrections on. Alpha receives the corrected file and rejects it because it has no formulas, only numbers. Beta Inc. must now purchase MS Office in order to output a compatible spreadsheet. At that point, they have to justify the expense of MS Office, and they have other customers that use it, so they decide to give up their existing software for MS Office, even though they had a perfectly good ODF-compliant office suit to begin with.
Note that this chain of events is broken if vendors simply keep the existing behavior. MS-ODF files would be found by Alpha to not be interoperable, and either they’d use a plug-in or they’d rethink using MS Office at all. They might choose to drop ODF as their general spreadsheet format, but most office suites can load proprietary Microsoft formats anyways, so interoperability would actually be improved. Better a tamed wolf than a wolf in sheep’s clothing.
Jakub Narebski says
See also late ODF Alliance Tests Microsoft Office 2007 SP2 ODF Support – Finds Serious Shortcomings article at Groklaw.
“The first correct step is probably that all ODF vendors start to output warnings when the ooxml namespace is encountered with information to the users that the document”
If you do so, users will think you are the faulty application, not Microsoft. That’s the clever trick.
Răzvan Sandu says
Here’s a link where one can download the future MS Office 2010:
Has anyone tested this, please, to see how the future “interoperability” will look like in MS world ?
(under pseudonym A Nonymous)
I think there *could* have been a defensible middle ground for MS to take on spreadsheet formulas.
If they don’t want to recalculate (and possibly come up with a different answer), they could simply protect both the formula cell, and all referenced/chained input cells.
After all, unless the input changes, the formula never needs to be used, and the ODF format specifies that the last output value is kept too.
By trashing formulas in other namespaces, MS has taken the lowest of low roads…
Chris Ward says
“Why should a dominant vendor help their competitors compete ?”
In a previous era, ATT were a dominant telephone service vendor. Should ATT allow inbound phone calls from, or outbound phonecalls to, customers who subscribe to non-ATT phone services ?
ATT were dominant in the USA, but not dominant in the rest of the world (e.g. Europe). Should they have interoperated with European phone services ?
If your products don’t interoperate with your competitors’ products, then your customers cannot interoperate with your competitors’ customers.
Nowadays, of course, there are all kinds of cellphone service vendors and ATT was broken up into ‘Baby Bells’ by the US Government.
Any any phone can call any other phone, across the USA (and throughout the world), no matter who provides the dial tone to each phone.
That’s good for consumers, and for consuming businesses.
That’s why you should interoperate.
Răzvan Sandu says
Hello, Rob & all,
Please, is there any news about ODF support in Microsoft products – any news since MS Office 2007 SP2 ? Are they going to change anything about it (via online updates) or it is "dead in the water" ?
For Office 2003 or for future Microsoft products (Windows 7, Office 2010), does someone have any clue ?
Thanks a lot,