Slashdot Log In
Microsoft Claims OpenDocument is Too Slow
Posted by
Zonk
on Fri May 26, 2006 08:09 AM
from the compared-to-the-blazing-speed-of-.doc dept.
from the compared-to-the-blazing-speed-of-.doc dept.
SirClicksalot writes "Microsoft claims that the OpenDocument Format (ODF) is too slow for easy use. They cite a study carried out by ZDNet.com that compared OpenOffice.org 2.0 with the XML formats in Microsoft Office 2003. This comes after the international standards body ISO approved ODF earlier this month." From the ZDNet article: "'The use of OpenDocument documents is slower to the point of not really being satisfactory,' Alan Yates, the general manager of Microsoft's information worker strategy, told ZDNet UK on Wednesday. 'The Open XML format is designed for performance. XML is fundamentally slower than binary formats so we have made sure that customers won't notice a big difference in performance.'"
Related Stories
[+]
OpenDocument Voted In By ISO 179 comments
cduffy writes "OpenDocument has been voted in as ISO/IEC 26300, with no dissenting votes and a small number of abstentions. There are still several formalities to take place before final issuance. Now the question: Will OpenXML get the same treatment, despite its technical weaknesses? There's also coverage on Groklaw."
This discussion has been archived.
No new comments can be posted.
Microsoft Claims OpenDocument is Too Slow
|
Log In/Create an Account
| Top
| 553 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
I don't know about the rest of you... (Score:3, Insightful)
(http://www.wittydomain.com/)
Re:I don't know about the rest of you... (Score:5, Funny)
(http://www.cafepress.com/gotmpg)
Re:Microsoft's Message is Loud and Clear (Score:5, Informative)
OpenOffice uses ODF. Office uses binary formats. The performance analysis quoted doesn't compare ODF and OpenXML. It states right in the article:
Here is a comparison with the standard 16-sheet SXC and XML sample file I've been using. The sample is in compressed XML format because it is smaller and easier for you to download. You'll have to convert the XML file to XLS and the SXC file to ODS to run the following test yourself.
XLS is a binary format. This study is irrelevant to the statements made. And it's the only data given to substantiate the claims made. So there is no data given at all.
All you can conclude from this is that OpenOffice 2.0, retrofitted recently for ODF, is much slower in a windows environment than Office 2003 using binary file formats. A far cry from any statements made either by Yates or by the summary.
What a pile of crap journalism.
Re:I don't know about the rest of you... (Score:4, Insightful)
Re:I don't know about the rest of you... (Score:5, Insightful)
(Last Journal: Tuesday December 19 2006, @05:12PM)
This is arguably analagous to Microsoft saying (about a format they can't control, which has been approved by the ISO as their open XML hasn't yet), "We'd support it but it's too slow"
Re:I don't know about the rest of you... (Score:5, Insightful)
(http://david.djsiska.cz/)
How about if someone with a Windows PC at hand compared the speed of opening and saving OpenDocument vs. the usual
I'm sure Microsoft would very much like to shift the debate from OpenDocument vs. Open XML to OpenOffice vs MS Office. Let's not fool ourselves MS Office has many advantages.
Re:I don't know about the rest of you... (Score:5, Interesting)
Not very scientific, but I tried to do this test. I opened a big Word doc I have (80 pages), and re-saved it in ODT using OpenOffice 2.0. Then I opened both docs a bunch of times (did them in different orders, sometimes with OpenOffice already open, sometimes not).
End result: OpenOffice 2.0 opens ODT about twice as fast as it opens Word
It is not surprising that OpenOffice opens its preferred (well-documented) format faster than it opens someone else's non-documented format.
The inverse test (opening both DOC and ODT in Word) is not possible for obvious reasons! However opening the
Conclusion: Word opening DOC is probably faster than OO2.0 opening ODT. However the difference is so small that no one should care (on modern hardware especially). Furthermore there's no reason not to believe that opening of ODT documents will get faster and smoother as time goes on, since the standard is published and algorithms for opening ODT can be improved openly with time. Not only that, but since OO2.0 is open-source, it's particular implementation can be improved.
On the flip side, just yesterday I tried using MS PowerPoint on a macintosh to open a big presentation (lots of graphs). Opening (and manipulating) the file was unbearable (took minutes to open on the Mac, even though MS PowerPoint on Windows opens it in a few seconds). Strangely Keynote opens it in a few seconds. So Microsoft even has trouble efficiently opening their own binary format! The idea that XML-based documents are "inherently" slow is silly. It has everything to do with the algorithm (which is good for MS Word, bad for MS PowerPoint for Mac, and decent for OpenOffice).
Re:I don't know about the rest of you... (Score:4, Interesting)
(http://www.ev4.org/)
It's quite disturbing how microsoft can't open their own format correctly, even with access to whatever documentation exists and full source code of an existing implementation.
Re:I don't know about the rest of you... (Score:5, Insightful)
(http://jinxidoru.blogspot.com/)
No, the idea that XML-based documents AREN'T "inherently" slow is silly. Of course an XML-based document will be slower than a binary document. XML gives a number of niceties, in the form of maintainability and platform-independence, but it can never be made faster than a well designed binary document. That's just the trade-off.
Re:I don't know about the rest of you... (Score:5, Insightful)
In fact, the study cited doesn't even refer to "the speed of ODF". It's about OO.o's speed only.
Re:I don't know about the rest of you... (Score:5, Informative)
(http://www.alexhudson.com/)
* they use single-letter tag names, for the most part, to reduce parsing time
* they remove all strings and put them in a look-up table
I'm not sure how much difference these things actually make in practice, but there's probably a little speed there.
What's not fair is to compare OOo to Microsoft Office, and determine the speed of OpenDocument versus OXML based on that...
Re:I don't know about the rest of you... (Score:5, Insightful)
* they use single-letter tag names, for the most part, to reduce parsing time
* they remove all strings and put them in a look-up table
Thing is XML was desgiend to be readable and easy to parse. If you start doing hacks like embedding tons of binary data (OpenXML has images embeded in the XML), using one letter tags and look-up tables, you've essentially a bloated binary format.
You can call it an XML, it's technically XML, but it really isn't.
It would be better that Microsoft offers an open binary format, but truly open, patent free. XML is really heavy compared to efficient binary formats. Compressing the resulting XML makes XML formats on par with binary as to size, but that's just faking it: the program will have to decompress it and parse an XML, which is tons harder that directly parsing binary offsets and bits (for a machine).
Re:I don't know about the rest of you... (Score:4, Insightful)
XML is a miserable failure on both counts. It may technically be readable, but it is excruciating. Easy to parse, it most certainly is not. About the only thing it has going for it, is that it is an extensible standard.
Re:I don't know about the rest of you... (Score:5, Insightful)
(http://honeypot.net/ | Last Journal: Friday April 07 2006, @09:33AM)
...and it can also be written with any program that can read and write text. Right now, today, I can generate valid OpenDocument files with standard Unix command line tools and simple "print" commands in common scripting languages. While that isn't valuable to the average user, it's extremely handy for those of us who want to generate documents dynamically with as little overhead as possible (example: sending quotes based on form input on a website).
Beyond that, XML is human readable (even if not terribly convenient). I can read well-designed XML documents with any text editor. 100 years from now, I'll still be able to glean the content of OpenDocument files with any program that understands by-then legacy encodings like ASCII. If a binary spec is lost, though, so are the documents written with it.
Re:I don't know about the rest of you... (Score:5, Insightful)
In other words if you don't have an ODF appilication all you have to do is unzip it( a feature found in most OS's these days) and extract the data by hand.
If you don't have MSFT Word of version x you can never open MSFT's formats. Patents will prevent third parties from implenting it. Defeating the entire point of having a standard.
Re:I don't know about the rest of you... (Score:5, Informative)
(http://www.intelligentblogger.com/ | Last Journal: Monday August 27, @11:47AM)
DOC files don't so much as stream as open for Random Access. They're structured in such a way that the information is stored as an object heirarchy scattered across the file. This makes saving faster because only the changes are saved to the file. It also make opening faster, because Office only needs to pull up the information that's on the screen at the moment. (Even if it's at the end of the document.) PDFs work in a similar, but more structured, fashion.
The unfortunate fact about ODF is that it requires a complete decoding of the file when loading, and a complete reencoding of the file when saving. However, I don't see any reason why Microsoft can't just add ODF support and make it an optional format. Computers are fast these days, and it should be up to the user to decide whether he needs the performance provided by the MS DOC *cough* "standard".
Or in other words, Microsoft is grasping at straws, trying to find a reason why they shouldn't support opening and saving of ODF files. I feel so sorry for them. (Not.)
Re:I don't know about the rest of you... (Score:5, Funny)
(http://www.rootedbox.com/)
Re:I don't know about the rest of you... (Score:5, Funny)
(Last Journal: Monday February 04 2002, @03:31PM)
Good god man, open your eyes!
(This analogy is fun! We need more like this one.)
INCITS (Score:5, Insightful)
(http://slashdot.org/~eldavojohn/ | Last Journal: Tuesday October 16, @03:26PM)
There was much speculation that Microsoft had joined INCITS with the intent to slowdown or stop the spreading use of ODF and insert their own standard. Sounded like another Microsoft power trip to me.
I predict that Microsoft will bitch and bitch about ODF and then release study after study suggesting some other patent laden format (probably Open XML) over ODF. This is just the first complaint against ODF--too slow. Perhaps next they'll complain that it's not documented well enough, some of their apps just can't support it, it gives their developers arthritis, it looks too ugly, etc.
Microsoft's upcoming ODF complaints: (Score:5, Funny)
If I was an MS shill. (Score:5, Insightful)
(http://whineymacfanboy.googlepages.com/ | Last Journal: Thursday April 12 2007, @09:28AM)
(read the 'study')
But I am sure the shills will pipe up with "easier to use", "people are used to it", "noone forces people to use MS" and other such irrelevance.
Re:If I was an MS shill. (Score:5, Insightful)
Although it is complete true that the distinction between application and document format is key, it is quite possible to design a document format with performance in mind versus merely counting on Moore's law to handle performance issues. My observation is that Microsoft has thought through some performance and reliability details to an impressive degree in OpenXML. The files are sorted in the zip file in the order that they are needed for incremental loading. The zip file is stream decompressed so that a lost bit halfway through the file does not prevent decompression of the beginning. Textual data is earlier in the file than bitmap data both because it is needed sooner and also because a truncated file will still have its text and basic formatting intact.
Obviously this Microsoft dude is not making any kind of fine distinctions. But I would love to see a careful analysis of the performance and reliability choices made in OpenDocument versus OpenXML if only so that OpenDocument can copy the best (unpatented) ideas from OpenXML. Microsoft has a lot of experience optimizing the performance of office suites and their file formats. I know from experience that those considerations tend to get lost in the standardization process.
Re:If I was an MS shill. (Score:5, Insightful)
(http://www.traxel.com/)
Performance optimization should be extremely limited before the product is feature complete and in the hands of at least expert customers, and preferably the real customers. Performance optimization is in tension with programmer friendliness. ODF is zipped ASCII XML with binary embeds (eg: raster graphics) stored in a separate part of the zip - it is really easy to generate documents (I have written a few apps that do it). MS XML is not going to be so easy - inline binary and lookup tables for content. Do you want nicely encapsulated code that can meet the customer's evolving needs without developing bugs (eg: Office's security holes), or do you want a document format that can run on a Pentium 60?
I work for a very large company that has had a number of teams developing code on several different ideologies for the five years that I have been here. I have been able to see up close the long term cost/benefit of teams that write heavily optimized code versus those that write code that is heavy on OO theory at the expense of performance (and versus those that write code that is neither clean nor fast, which is kind of funny/painful to watch). In the long run, there is no competition - the maintainable code wins hands down for anything that has evolving customer needs (which, except for those that have been cancelled, is every project I have seen).
The zip file is stream decompressed so that a lost bit halfway through the file does not prevent decompression of the beginning. Textual data is earlier in the file than bitmap data both because it is needed sooner and also because a truncated file will still have its text and basic formatting intact.
That is the very epitome of inappropriate technical magic put in place by the, "Shouldn't our code handle hypothetical situation X?" people. It makes the code harder to write, understand, and maintain, and it solves a problem that doesn't happen in normal operating conditions. If there's a problem with software or hardware failures during write, do what OOo and MSO already do - keep a backup while the file is open. Once the file is on disk, it is very unlikely to be truncated or bit-flipped unless the drive goes bad (in which case you are going to have a hard time recovering it anyway). If you need your data to withstand drive failures, use an off-disk, off-site, or off-line repository as appropriate.
Re:If I was an MS shill. (Score:5, Insightful)
I'm not condoning or defending this particular study (although I have to admit, to me it smacks of "Company rubbishes competitor, talks up own product - film at 11"), I'm just getting a little weary of seeing all the calls of troll, shill and astroturfer levelled at anyone with an opinion that differs from that of the collective.
(And before anyone says it, yes, that goes for both sides, Linux zealots and MS weenies alike)
Re:If I was an MS shill. (Score:5, Insightful)
Here's 3:
Because we find the slashbots' misinformed, knee jerk, MS bashing tedious?
Because we find that often, their tools are a good solution for our problems?
Because we aren't interested in fighting the Linux Jihad?
Re:If I was an MS shill. (Score:5, Insightful)
a prim example is look at compressed archives.. say RAR.. if you look at the diffrence between a normal RAR archive and a Solid RAR Archive. the Solid archive takes all the files and treats them like a TAR ball so that you can compare like data and get better compression.. It doesn't take much longer to create the orginal file than a normal RAR archive which treats each file on it's own basis but when extracting or updateing you have to read through every file before the one you want in the archve when reading. and when writing you have to read all the ones before to evaluate the one you have and change it and then progress and extract and recompress every other file after it instead of just skooting them over when updateing a normal archive.
both methods use the same compression methods and are of the same type and data types.. one gives you better compression but is and is faster to extract but is horid at random openings and updates where as a normal archive doesn't have the horid side affects but doesn't give you the higher compression or the speed in extracting.
One thing MS has always been very good at is making MS Word fast. the load times are impressive and the save times like wise. forget about the stability for the moment and give them credit for being fast.. now i know TFA is fud and stupid but there might be a legit argument. MS knows how to make doc files fast, they designed them to be - if ODF wasn't as thought out for speed i could see it being an issue for anyone trying to implement it, and with some implementations there really is no way to make it faster.
It is just something to think about. While the artical is dumb the argument could very well be legit. people should bash it just because it has MS writen all over it.
It's a fucking WORD PROCESSOR (Score:5, Insightful)
It's not a game loading complex 3D worlds and sound effects, it's a load of text being displayed on screen. What difference does a few milliseconds here or there make? OpenDocument could be ten times slower and the benefits of an open document format would still vastly outweigh the effects of loading time.
Re:It's a fucking WORD PROCESSOR (Score:5, Insightful)
(http://rustyp.freeshell.org/ | Last Journal: Tuesday April 29 2003, @09:22AM)
Oh wait...it has been done. By Microsoft too, in fact. IE, Mozilla, and Opera are all capable of much more than ODF and at ridiculously high speeds.
If you add to that the fact that the MS version actually has more useless features in it (which add to the parse time), I guess this is entirely a lie.
Haven't they defended that one themselves? (Score:4, Insightful)
(http://www.drivesentinel.co.uk/)
"Any performance limitations now will be resolved as Moores Law continues"
Not that I like the argument.
Something important to remember (Score:5, Insightful)
(http://www.oldos.org/)
I see this as an attempt by Microsoft to slander this format and try to further their own semi-OpenXML format.
--
Jason Faulkner
Eastern US Press Contact
OpenDocument Fellowship
the new MS tag line... (Score:5, Funny)
(http://thepreacher.cac2.net/)
"Microsoft, saving your life, one microsecond at a time..."
Format Slow? (Score:4, Insightful)
(http://jimk.redcolony.com/)
Re:False dichotomies (Score:4, Informative)
With old style formats, you knew that the header was 512bytes followed by 600 bytes of meta data, followed by the document sections which all indicate their size (or have some way of calculating it based upon the block type)
With XML, you get a tag opening and have to parse until the closure, this adds a lot to the complexity of reading.
Writing is slightly different, and should infact be simpler with XML even though it may be more verbose, you don't need to buffer the entire block or rewrite the section header to indicate the length, you just happily do a sequential write.
Re:False dichotomies (Score:5, Informative)
ODT XML files are binary files. So are old Word 2003
When people say "binary files" they mean this as opposed to "text files", a seperation that stems from the ability to open a file for in "binary" or "textfile" modus in several APIs. Has to do with, amongst others, interpretation of control codes such as ^Z.
The other big mistake: file formats aren't fast or slow. The algorithms for reading and writing them are (or aren't) slow.
*slaps cheek* NO WAI!
You fail to see the point of what they're saying. They're saying a binary file, with a header and fixed data structures, are alot easier to read & parse than an XML file, which consists of structures of variable length, needs to be interpreted, etc etc etc. This is a problem with XML.
in RAM? (Score:3, Insightful)
(http://127.31.33.7/)
And in earlier news, unbundling IE from Windows... (Score:4, Funny)
(http://www.dpbsmith.com/)
Well, actually, now that you mention it, a professor and his student did remove it, but you can't call it successful, because um, performance, sure, that's right, in our labs our very own scientific technical unbiased tests showed that because of ferthbernder sprocket-flange snap-toggle linkage, when you removed IE using the professor's techniques, it reduced Windows performance by a lot of percent. No user would accept this, any more than they would accept the reduced performance of WIndows on a year-old PC.
We will now show you just how severe this performance problem is.
Right here. In this very courtroom.
With a faked demo^h^h^h^h^h^h^h^h^h^h a dramatic, animated illustration presented right on the screen of an actual PC.
It seems you're trying to load an XML document... (Score:5, Insightful)
If a Windows-capable PC has enough oomph to render clippy in 3-D translucent splendor for Vista, then it's certainly fast enough to load an XML document.
The rest of the quote (Score:5, Funny)
(http://www.michaelmaggard.com/ | Last Journal: Wednesday January 11 2006, @12:39AM)
Study = 1 Blogger running one test (Score:3, Insightful)
He had a humongous spreadsheet (a couple hundred megabytes) and was tracking the load time.
He whined about the memory OO takes, and didn't mention that MSOffice pre-loads its stuff on startup, so you are loafing MSOffice stuff whether you need it or not.
Uhmm... (Score:5, Insightful)
OPTIMIZE YOUR CODE!
I know that there are many variables here, but seriously... how slow can it be? I use OpenOffice 2.0 on an Athlon64 3200+ and I have no issues, in fact, I find it much quicker than M$ Office
For those two people not in the know... (Score:3, Informative)
All in all - OOo's file formats are a nice and simple solution for exchanging reasonably sized documents (if you don't mind usual XML-namespace-hell structure) but for editing/working on larger documents/spreadsheets you may find yourself using MSOffice document formats (from within OOo). Pity they don't provide their own "scratch-pad/database-in-a-file" formats.
So - for once, Microsoft is kinda right here.
Re:For those two people not in the know... (Score:5, Informative)
(http://honeypot.net/ | Last Journal: Friday April 07 2006, @09:33AM)
TeX consists of long streams of ASCII bytes and offer no random-access abilities whatsoever except those implemented by a text editor and the underlying filesystem. And yet, LyX, which can easily handle thousand-page documents, loads and saves nearly instantaneously.
Your complaint is really over the relative brokenness of two major office suites, not the inherent advantages of their document formats.
RTFA. (Score:3, Interesting)
Mr.Yates says OpenXML has been designed with performance in mind, whereas ODF is not. A binary format such as
I wouldnt know if this was actually the case; however, it would be good to investigate if the claims were true. OpenOffice could very well do with a major performance boost. A lean,well-designed XML schema cannot hurt.
Does this really surprise anyone? (Score:4, Funny)
(http://www.random--precision.org/ | Last Journal: Wednesday May 17 2006, @10:35AM)
Perhaps next they'll claim that ODF is so slow that it's causing Vista to be late to market.
MS App Tweaks (Score:5, Interesting)
It kind of makes me wonder if they'll try the same approach to make ODF look "slower," by optimizing MS apps to work with Open XML and fumble around with ODF files.
Oh noes! (Score:3, Insightful)
(http://www.fbxl.net/ | Last Journal: Saturday June 23, @05:12PM)
Oh Right... (Score:5, Insightful)
(http://www.flying-rhenquest.net/)
In fact, until this very day I didn't even realize that performance was even in Microsoft's dictionary, and like so many other words Microsoft uses I don't think it means entirely what they think it means. Newsflash, Microsoft, "innovation" does not mean "steal other people's ideas." "Security" does not mean "It'll be taken over before you can download the first update for it." And "performance" doesn't mean "the entire fucking system stops for 30 seconds when some application decides to stop handling its windows controls." Now STFU [stfu.se] and go back to pushing your poison kool-aid on unsuspecting consumers before Apple eats your lunch.
faster and smaller can be far worse (Score:4, Interesting)
using a text editor, would you rather try to fix a bug in an odf or ms xml file?
MS XML
<w:p>
<w:r>
<w:t>This is a </w:t>
</w:r>
<w:r>
<w:rPr>
<w:b
</w:rPr>
<w:t>very basic</w:t>
</w:r>
<w:r>
<w:t> document </w:t>
</w:r>
<w:r>
<w:rPr>
<w:i
</w:rPr>
<w:t>with some</w:t>
</w:r>
<w:r>
<w:t> formatting, and a </w:t>
</w:r>
<w:hyperlink w:rel="rId4" w:history="1">
<w:r>
<w:rPr>
<w:rStyle w:val="Hyperlink"
</w:rPr>
<w:t>hyperlink</w:t>
</w:r>
</w:hyperlink>
</w:p>
OpenDocument
<text:p text:style-name="Standard">
This is a <text:span text:style-name="T1">
very basic</text:span> document <text:span
text:style-name="T2"> with some </text:span>
formatting, and a <text:a xlink:type="simple"
xlink:href="http://example.com">hyperlink
</text:a>
</text:p>
Fileformat performaces (Score:5, Insightful)
Personally I already have seen this kind of numbers, even though I've never minded to measure them.
Why? Simply put, because it matters very little.
Compared to Windows 3.11, Windows XP needs 100 times more disk space, 10 times more RAM and 10 times more time to boot.
Compared MS to Word 5.5, MS Word 2003 if slower and bigger.
Today I wouldn't revert back to Windows 3.11 and would not choose Word 5.5. What'd be the most important features expected in a document file format? In my opinion:
1. compactness
2. openness
3. flexibility
No "access performances", though.
Because the time needed to load a document, when you do real office work, weighs by far less than the time you spend on it while working.
And when someone sends you a file written with a different version of the software or even with a different software, how much time do you spend to make that file readable and printable?
algorithms for fast compression & handling of (Score:4, Interesting)
(http://fph.altervista.org/)
Reminds me of 'performance speak' from psych paper (Score:5, Informative)
(http://stable.cowoh.org/)
This issue is about Microsoft defending their turf rather than not wanting to learn something new. But it's basically the same motive at work: find ways to undermine the new to benefit the old.
It goes on, "This model of learning also explains other surprising behavior that I frequently observe. I have seen novices in software development with knowledge of a single programming language explain to experienced expert developers why their choice of programming language was a particularly bad one. In one case, I talked to a student of computer science who told me why a particular programming language was bad. In fact he told me it was so bad that he had moved to a different university in order to avoid courses that used that particular language. When asked, he admitted he had never written a single program in that language. He simply did not know what he was talking about. And he was willing to fight for it. With respect to programming languages, negative opinions about a language that a person does not know, are usually based on very superficial aspects of it. To people obsessed with performance lack of such in a programming language is a favorite reason to advocate its eradication (even though performance is not a quality of a language, but of a particular implementation)."
The positive lesson to take away from this is the MS is undoing itself. It's turning to cheap, nasty, suit-driven mentalities to defend its turf rather than the old days when it would just go out and write something new and nasty. It's become an unwieldy beast. I read about the Vista delays yesterday and briefly thought "Will anyone notice - who uses Windows these days". To an extent it shows what a bubble I live in. But it's true - *all* of my regular contacts use linux, freebsd or mac os x. As they should. After all - friends don't let friends use Windows.
Well... is it $200 slower? (Score:5, Insightful)
Because "free" still means more to me than an additional 1.7 seconds.
Eh? (Score:3, Insightful)
(http://pthbb.org/)
Why the hell does a text editor need to block the UI while writing to disk?
MS is claiming this for a long time (Score:3, Interesting)
I use both offices suites at work and at home and the speed difference is in the order of 2x at most for the first loading of the program and almost no difference after this (anything below 1 second is just "fast enougth" for me). And my computer is rather outdated.
I think ms Office a fair software, not worth the price, that's really expensive in Brasil, but they don't need to lie this way to sell it...
Deliberate Confusion Between File and App (Score:3, Insightful)
(http://www.friendwich.com/ | Last Journal: Thursday November 09 2006, @12:05PM)
They deliberately confuse the application with the file format.
Psycologically reinforcing the perception that everything in a computer is vertically oriented and "incompatible" unless it comes from our application.
They understand the immense threat that a viable alterative (file format in this case) presents. PHB gets idea, "If this is iteroperable, gee I wonder what else is?"
Beautiful.