Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Stephane Rodriguez Dismantles Open XML

kdawson posted about 7 years ago | from the some-kind-of-joke dept.

Microsoft 188

Elektroschock writes "Stephane Rodriguez, a reengineering specialist who became popular for his article on MS Office 2007 binary data, now comprehensively debunks Microsoft's new Open XML format. With small case studies he demonstrates the impossible challenges third-party developers will face. His conclusion: it is 'defective by design.' Next week members of the International Standard Organization are likely to approve the format as a second official ISO standard for office documents, even though most nations have submitted comments. Rodriguez claims he is 'not affiliated to any pro-MS or anti-MS party/org[anization]/ass[ociation].'"

cancel ×

188 comments

Sorry! There are no comments related to the filter you selected.

fritsy piss!! (-1, Offtopic)

Anonymous Coward | about 7 years ago | (#20361223)

A[nonymous] C[oward]

This is not proof of OOXML being defective by desi (3, Insightful)

tsa (15680) | about 7 years ago | (#20361263)

This is not proof of OOXML being defective by design. It only shows that apparently MS's software isn't able to handle OOXML properly.

Re:This is not proof of OOXML being defective by d (4, Insightful)

darkatom (94914) | about 7 years ago | (#20361313)

But that's still a problem. Microsoft's implementation becomes the de facto standard and all others must (attempt to) conform to the behavior of that implementation or be judged defective. This is what happened when MS published the MAPI (Mail API) spec and then released an implementation alongside it. Lotus and others could never fully mimic what the MS implementation did, so they eventually languished.

Re:This is not proof of OOXML being defective by d (1)

GIL_Dude (850471) | about 7 years ago | (#20361979)

I seem to recall Lotus didn't like MAPI and wanted to push their own API called VIM? (http://en.wikipedia.org/wiki/Vendor_Independent_M essaging).

Re:This is not proof of OOXML being defective by d (1)

Gription (1006467) | about 7 years ago | (#20363983)

Seeing that MS controls the platform and the platform calls MAPI it seems like a silly battle to fight.

To go back and reiterate darkatom's comment: Microsoft has always taken 'standards' and extended them to break everyone else's version except theirs. Nothing has ever stopped them except a court order (like JAVA, maybe...) but if they don't dominate and control they always try to take their ball and go home. ("I'll see your JAVA and raise you an Active-X (who cares if it makes using the web uncontrollably dangerous!)")

Re:This is not proof of OOXML being defective by d (3, Insightful)

Anonymous Coward | about 7 years ago | (#20362761)

Microsoft's implementation becomes the de facto standard

No, I don't think so. It will serve Microsoft's purposes better if they too cannot properly implement the OOXML standard. Then their fully proprietary file formats would continue to be used since no one could trust that an OOXML document hasn't been corrupted by the OOXML save process.

This is how Microsoft destroyed the nascent RTF standard that the US Navy wanted to use: they implemented it, but gee there were problems in getting it to work right so maybe all you sailor boys should use Word's native file formats until we get things worked out (which never happened).

Windows just don't belong on a battleship or aircraft carrier. You would have thought the US Navy would have known that, but no, they had to go and try it anyway.

Re:This is not proof of OOXML being defective by d (2, Interesting)

tsa (15680) | about 7 years ago | (#20363289)

But that's still a problem. Microsoft's implementation becomes the de facto standard and all others must (attempt to) conform to the behavior of that implementation or be judged defective.

I wonder what happens if OOXML is not voted a standard. Will MS simply discard it, and embrace ODF, or will they continue to use .doc as if nothing happened? I guess they will do the latter since it's the most economical option for them. If that happens I'm curious what the EU will think of that, and how long it will take before MS is forced to use ODF as standard, if it ever comes to that.

Re:This is not proof of OOXML being defective by d (5, Informative)

Anonymous Coward | about 7 years ago | (#20361327)

"by design" is of course about motivation which we can know in OOXML from emails, quotes, obtuse or brittle design, and lack of specification.

The document contains all of these. I suggest that you read it.

By the way -- there's newly discovered undocumented Microsoft tech present in OOXML, such as SSPI ("Security Service Provider Interface") which is a proprietary Microsoft developed protocol for security providers, and OLE ("Object Linking and Embedding") which is for embedding (eg, taking an Excel spreadsheet and putting it into a Word document). This is undefined in OOXML only available on Microsoft Windows.

Org/Ass (-1, Troll)

Anonymous Coward | about 7 years ago | (#20361867)

I love how FOSSies always say they aren't affiliated with any pro- or anti- Lunix group. Notice he never claimed he was impartial: this guy is, just like most other Slashdotters, a dyed-in-the-wool FOSSie, gleefully spreading anti-MS FUD.

But... they are unaffiliated, so by their conservative propagandizing, that must mean they are unbiased.

Re:Org/Ass (1)

smitty_one_each (243267) | about 7 years ago | (#20364447)

The motives of the MS critic run the gamut.
Some are pro-Linux as you say.
Others are pro-BSD.
Still others are equally proprietary, from the OS X community for example.
What unites them? The ABM Treaty: Anything But Microsoft.
What part of "level playing field" and "conformance to standards developed in the traditional manner" (e.g. not the OOXML SUV-flanking movement) seems odd, biased, or unreasonable, Your Anonymity?

Re:This is not proof of OOXML being defective by d (1, Troll)

man_of_mr_e (217855) | about 7 years ago | (#20362785)

Dude. You do realize that OpenOffice also has OLE and SSPI support, right? These are platform specific features, and any office product on Windows has to support them, or they won't be very popular.

You're not coming up with some kind of revelation. It's more of a "Duh, no shit sherlock".

Re:This is not proof of OOXML being defective by d (1)

Anonymous Coward | about 7 years ago | (#20364053)

What an irony that Microsoft is having to embrace and extend its own file format

Re:This is not proof of OOXML being defective by d (4, Interesting)

bomanbot (980297) | about 7 years ago | (#20361331)

This is not proof of OOXML being defective by design. It only shows that apparently MS's software isn't able to handle OOXML properly

Um, isnt the fact that not even Microsofts own software can handle OOXML which btw. is designed by Microsoft themselves, proof enough that something is seriously wrong with the design of OOXML?

I mean if not even the maker of OOXML can get it to work properly in its own products, how are third parties supposed to do it? And if no one is able to implement OOXML correctly, what is this "standard" good for besides being a great smoke-and-mirrors tactic by Microsoft themselves?

Re:This is not proof of OOXML being defective by d (5, Insightful)

setagllib (753300) | about 7 years ago | (#20361349)

It's deliberate. The standard is just a distraction, to keep competitors busy trying to implement it, while documents are actually being created in the Office 2007 variant of OOXML. A few months of legacy almost guarantees a transition to the real OOXML would be an uphill battle, especially with no real documentation of how *either* format works. So even with a supposed 'standard' and a near-enough implementation, the vendor lockin is just as strong as it was with the binary formats.

Smokescreen for Sharepoint (4, Interesting)

Sweetshark (696449) | about 7 years ago | (#20361441)

This "OpenXML" stunt is just a smokescreen covering Microsofts controlled retreat in the office format battle. It only needs to keep parties distracted until Microsoft has reclaimed the control over business content by means of vendor lockin v2.0 aka Microsoft Office Sharepoint Server.

http://weblog.infoworld.com/openresource/archives/ 2007/04/while_you_were.html [infoworld.com]
http://www.itbusinessedge.com/blogs/mia/?p=198 [itbusinessedge.com]

Re:This is not proof of OOXML being defective by d (3, Informative)

zlogic (892404) | about 7 years ago | (#20361527)

Still it's better than the original DOC format.
A DOC is actually a FAT12-like filesystem (called OLE) that has files and clusters. Clusters can be lost and files can be fragmented. One of the files is the document's text; it's not plaintext but rather another obscure binary format, with text chunks seperated by some kind of metadata (my brain nearly exploded when trying to understand how to separate text from the metadata and I gave up). Images, videos and embedded objects are stored as separate files in the OLE file.
Instead of a simple *.zip file with an HTML-like text file they invented a completely fucked up format that gives people nightmares. The only point is making third-party compatible applications is extremely difficult, but the plan seems to have backfired because even Microsoft's own Word Mobile doesn't work well with native *.doc files (and ironically, Documents To Go for PalmOS works better with DOC than Word Mobile!)

Re:This is not proof of OOXML being defective by d (1)

maxume (22995) | about 7 years ago | (#20363431)

Part of the reason it is designed that way is that back in the dark ages, when it mattered a bit more, it was faster than a simple zip with an HTML-like text file.

Re:This is not proof of OOXML being defective by d (-1, Troll)

Anonymous Coward | about 7 years ago | (#20361947)

I mean if not even the maker of OOXML can get it to work properly in its own products, how are third parties supposed to do it?


Well, that perfectly describes Sun and Java. So that means Java is defective by design, since Sun doesn't use Java on a single one of their internal projects (it's banned by policy).

Your statement is also propaganda... because OOXML isn't a released product yet: it's still being developed. So obviously MS doesn't have any products using OOXML. But Java is out in the wild, and has been for years. So I guess all you FOSSies are going to stop using the "defective by design" Java. Right?

And what about teh Lunix? They've been releasing new versions of the kernel since it was released. It's a shame they couldn't have been bothered to code it right the first time. Or the second, third, forth, ad naseum times. So... Rodriguez is saying teh Lunix is "defective by design", as well (although actually, she may have a point. Even the guy in charge of "Lunix on teh desktop" quit in frustation: he was tired of putting a round peg into a sqare hole. Oh, and he blamed his failure on MS, so you can be assured he was a true FOSSie).

Re:This is not proof of OOXML being defective by d (1)

dwarfking (95773) | about 7 years ago | (#20362511)

since Sun doesn't use Java on a single one of their internal projects (it's banned by policy)

Sources please?

Java and the Lunix... defective by design? (0)

Anonymous Coward | about 7 years ago | (#20363179)

You have a good point. If OOXML is defective by design because it's not implimented by MS... despite not even being a released and solidified standard, that must mean Java (which Sun itself doesn't use) is defective by design. And likewise, teh Lunix must be defective, since they keep having to rewrite it and come out with new versions. It's high profile failures are also proof of this, like how Munich's total Lunix conversion has been a disaster, and they've been trying since 2002.

Re:This is not proof of OOXML being defective by d (0)

plague3106 (71849) | about 7 years ago | (#20361957)

Um, isnt the fact that not even Microsofts own software can handle OOXML which btw. is designed by Microsoft themselves, proof enough that something is seriously wrong with the design of OOXML?

No, because the manually edited document did not conform to the standards. I read what the author did; basically he seems to think that a document conforming to a standard must: 1) be easily modifiable by hand. 2) That you should be able to open the document and start editing away without knowing the spec. In the end, he basically is saying "its too complex to manually modify!!" Which is absurd; a program should be doing the modification, one built to adhere to the specification. Nothing about a standard says that it need work with notepad just because its based off of xml.

I mean if not even the maker of OOXML can get it to work properly in its own products, how are third parties supposed to do it? And if no one is able to implement OOXML correctly, what is this "standard" good for besides being a great smoke-and-mirrors tactic by Microsoft themselves?

You assume his manual edits were done according to spec, which is not likely given that the spec seems pretty complex. I would say that Excel handles it fine, as long as you obey the specfication. A third party will need to invest some time making a standard compliant reader / writer, but once its done, its done.

Its not that you can't implement it properly; its that doing so in notepad will prove very time consuming and error prone. But that doesn't suprise me; its meant to be done in an automated fashion anyway. May as well complain that you can't telnet to a DNS server and manually talk to it successfully.

Re:This is not proof of OOXML being defective by d (1)

notasheep (220779) | about 7 years ago | (#20363277)

I agree with you about everything except the part about Excel handling it fine. I'm using Excel 2007 and have many spreadsheets with large data tables. Moving the columns around in the table (something the old file format did flawlessly) very often results in the "Unreadable content error" the next time you open the file. An extremely frustrating thing to happen, because when it does it kills your data table.

Re:This is not proof of OOXML being defective by d (2, Funny)

man_of_mr_e (217855) | about 7 years ago | (#20362817)

No. What it means is that Office has so much legacy code that they can't rewrite it all to be conformant. Think of OOXML as a target that MS feels they can eventually meet with office, not necessarily what office will actually meet today. After all, much was changed in OOXML after Office 2007 went to bed. One would expect the next version of Office to be much closer to the spec, since they will have had a full design cycle to conform to it.

Re:This is not proof of OOXML being defective by d (5, Funny)

David Gerard (12369) | about 7 years ago | (#20361333)

OOXML is a theoretically perfect standard that just happens to have no implementations whatsoever.

Re:This is not proof of OOXML being defective by d (2, Funny)

Shados (741919) | about 7 years ago | (#20361761)

Oh nice! So you mean the W3C took it over?

Re:This is not proof of OOXML being defective by d (2, Insightful)

edxwelch (600979) | about 7 years ago | (#20361499)

You are correct.
That's why the title says "Microsoft Office XML Formats? Defective by design"
not "OOXML defective by design"
He is dissing the Microsofts claims of transparency and openness of Microsoft Office XML

Re:This is not proof of OOXML being defective by d (3, Interesting)

canuck57 (662392) | about 7 years ago | (#20361509)

This is not proof of OOXML being defective by design. It only shows that apparently MS's software isn't able to handle OOXML properly.

OK, lets have MS have their choice either way on this one.

If their office tools work well but are not using the OOXML spec, they must be using some other spec, perhaps MOOXML. In which case they are not OOXML compliant.

On the other hand, if they want to be OOXML compliant then I guess Redmond programmer can't read their own spec and thus are having problems being compliant.

Either way, and for whatever reason Microsoft is not compliant with their own spec. Shall we call this MOOXML? And while I have only read a part of the spec, it is far too "undefined" and thus ambiguous to be reliable used by itself. A standard needs to be defined enough, that 2 or more parties could take the standard document specifications, run off and program it from scratch. And have a reasonable chance that their code will inter operate on the same data sets.

Trouble is, if Microsoft cannot do that, how is anyone else?

But might I submit, Microsoft wrote office and then wrote the spec. A poster child of why you think about and write the spec before the software is a good practice.

Re:This is not proof of OOXML being defective by d (1)

man_of_mr_e (217855) | about 7 years ago | (#20362861)

Did it ever occur to you that the Office 2007 was finished before the OOXML spec was? Remember, there were many changes in ECMA comittee long after Office 2007 was finalized.

Re:This is not proof of OOXML being defective by d (3, Funny)

orcrist (16312) | about 7 years ago | (#20364515)

Did it ever occur to you that the Office 2007 was finished before the OOXML spec was? Remember, there were many changes in ECMA comittee long after Office 2007 was finalized.


My guess is, yes, it occurred to the poster you were responding to, since I highly doubt that when he wrote exactly that, it was in his sleep. Did it occur to you that reading his post all the way to the end might have resulted in slightly less of your foot being inserted into your mouth? ;-)

Re:This is not proof of OOXML being defective by d (0)

Anonymous Coward | about 7 years ago | (#20361815)

But that is the surprise:

See
http://www.noooxml.org/ [noooxml.org]

and
http://www.noooxml.org/arguments [noooxml.org]

The format is broken
Ms Office support of the format is broken
microsoft: Let's break ISO.

Re:This is not proof of OOXML being defective by d (0)

Anonymous Coward | about 7 years ago | (#20361819)

There is now an overwhelming literature on why OOXML should be refused acceptance as a standard by ISO.

The real question is why it is about to be endorsed as a standard. Is this just the power of money and influence?

It all beggars belief.

Re:This is not proof of OOXML being defective by d (5, Insightful)

swillden (191260) | about 7 years ago | (#20361847)

This is not proof of OOXML being defective by design. It only shows that apparently MS's software isn't able to handle OOXML properly.

If Office can't read OOXML files produced by other tools, and other tools can't read Office OOXML files, where do you suppose end users will place the blame?

And what do you suppose users will do when faced with incompatibilities?

It's a brilliant strategy: Define a new "standard" but don't quite implement it yourself, ensuring that no one can implement a competitive office suite that is compatible with yours. Further, make the standard complex and weird enough that you can always blame inconsistencies on the other implementations. Voila! You get to proclaim to the world that your de facto standard office suite supports an open, ISO-blessed international standard format -- but with no worries about losing your lock-in.

Re: Brilliant Strategies (3, Insightful)

TaoPhoenix (980487) | about 7 years ago | (#20363059)

Don't forget the delicious language. Instead of the legendary "syntax error", we now get a "catastrophic failure". Do it yourself FUD!

(Scene at office)
ComputerGuy: "Sure, let's open that with GoogleApps."
Colleague: "Why am I getting a catastrophic failure? Maybe I better use Excel."

Re:This is not proof of OOXML being defective by d (1)

miguel (7116) | about 7 years ago | (#20363685)

This is not proof of OOXML being defective by design. It only shows that apparently MS's software isn't able to handle OOXML properly.

If Office can't read OOXML files produced by other tools, and other tools can't read Office OOXML files, where do you suppose end users will place the blame?

And what do you suppose users will do when faced with incompatibilities?


but Office can read OOXML files produced by other tools; You just have to generate proper files.


As its pointed out in this thread:


http://blogs.msdn.com/brian_jones/archive/2007/08/ 15/why-there-s-no-microsoft-in-open-xml.aspx [msdn.com]


Stephane basically wanted a shortcut, and gets upset that he can not use a shortcut. This is equivalent to complaining that a web browser wont display things properly when you feed it invalid CSS.


In addition, Excel happens to recover nicely from the lack of data that Stephane complains so loudly about, you just happen to get a warning if the file you feed it happens to be incorrectly formed and even offers you an option to "repair" it.

Re:This is not proof of OOXML being defective by d (3, Insightful)

swillden (191260) | about 7 years ago | (#20364435)

In addition, Excel happens to recover nicely from the lack of data that Stephane complains so loudly about, you just happen to get a warning if the file you feed it happens to be incorrectly formed and even offers you an option to "repair" it.

Yep. Brilliant, isn't it. Given a horribly complex and incomplete specification, Microsoft can easily blame any problems on the other tools -- and they can do this with a straight face because they'll be right! (Quietly ignoring the fact that their own tool produces non-compliant OOXML). Even better, they can smugly point out how their tools fix the "errors" caused by other crappy tools, even as the text of their messages frighten users away from trying any tool that doesn't come from Microsoft ("catastrophic failure", no less!).

If MS weren't trying to pull a fast one, they'd have designed a more reasonable format, one that does make it practical to make small edits to the XML and expect reasonable results or, even better, used an existing standard like ODF. If ODF can't fully represent all facets of Office documents, the format has a well-defined technical and procedural path to add any necessary extensions.

By way of comparison, try the same series of experiments with a .ods document, using any of the handful of available applications that supports it, and you'll quickly see how a format that is designed to be straightforward, accessible and specifiable in less than 500 pages compares to the brilliantly-executed monstrosity that is OOXML.

Mod parent up (1)

Lonewolf666 (259450) | about 7 years ago | (#20362715)

The examples given by Rodriguez do indeed only prove that Microsoft's implementation sucks. Parent's assertion is correct.

On the other hand, a rather lengthy list of objections against the standard itself can be found here:
http://www.grokdoc.net/index.php/EOOXML_objections [grokdoc.net]

So it seems that both the standard and its implementation suck ;-)

I disagree (1)

jbengt (874751) | about 7 years ago | (#20363099)

Some of the complaints only indicate that MS sucks at implementing it's own standard.
Other complaints are with the format itself, such as numerous different ways of marking up the same thing; dependencies hidden in various files instead of listed up front (forcing a parsing of the entire zip file to make a trivial change); inclusion of proprietary, undocumented, or partially documented parts, like VML; including assinine legacy structure, like the way dates are improperly stored, and on and on.

Re:This is not proof of OOXML being defective by d (1)

man_of_mr_e (217855) | about 7 years ago | (#20362775)

It should also be pointed out that many of his complaints would require application specific extensions in ODF as well. i.e. ODF doesn't define a way to encrypt documents, or store filesystem metadata. Where he talks about calculation chains and other aspects that have no equivelents in current ODF documents because of a lack of spreadsheet formula definition, etc...

Basically, many of his arguments could be said about ODF (though not all), since ODF doesn't provide a standard way to do those things, they would therefore have to be application dependant.

Re:This is not proof of OOXML being defective by d (1)

Bert64 (520050) | about 7 years ago | (#20363323)

I always figured that, since an ODF file is basically zipped, an encrypted ODF is just an encrypted ZIP.

Re:This is not proof of OOXML being defective by d (0)

Anonymous Coward | about 7 years ago | (#20363467)

Do not get me started on the ever decreasing competence level at Microsoft. One of my daily tasks is dealing with and MS provided XML datastream. It's incredibly rigid and the protocol devoid even the most basic functions. This is no shock to me, having dealt with M$oft at the byte level since the early 90's. Ugh, why do I even waste time reading about M$soft stupidity.

As a mentor of mine once said. "Microsoft makes money, in spite of itself".

Disingeneous (4, Informative)

golodh (893453) | about 7 years ago | (#20364489)

I see three questions here:

-Q(1) What does Rodriguez's article show?

-Q(2) is OOXML in and by itself flawed?

-Q(3) What's the practical relevance of the question whether OOXML is flawed?

-Q(4) So what's in it for Microsoft? Why do they bother?

-

- Q(1) : What does Rodriguez's article show?

- A(1) : Rodriguez's article show that the OOXML format written by latest Microsoft Office applications, among them MS Excel, is:

- sorely defective in that you can't be sure to get your original data back after saving it to OOXML

- impossible to change outside MS Office applications

- tied to the MS Office way of representing internationalised versions of documents because "of the way Microsoft chose to store XML using the US English locale, no matter how good your implementation is, you have to retrofit it to work just like Office does" in order to accommodate internationalised documents

- MS Office legacy formats supported throughout, greatly (and unnecessarily) contributing to the size and complexity of the 6,000 page standard.

- Q(2): Is OOXML flawed in and by itself?

- A(2):Yes, I think so, partly because of Rodriguez's article, partly because of flaws documented elsewhere: see http://www.noooxml.org/petition [noooxml.org] The points 2,3,4,5 listed there seem especially crippling to me:

(2) There is no provable implementation of the OOXML specification: Microsoft Office 2007 produces a special version of OOXML, not a file format which complies with the OOXML specification;

(3) There is information missing from the specification document, for example how to do a autoSpaceLikeWord95 or useWord97LineBreakRules;

(4) More than 10% of the examples mentioned in the proposed standard do not validate as XML;

(5) There is no guarantee that anybody can write software that fully or partially implements the OOXML specification without being liable to patent lawsuits or patent license fees by Microsoft;

- Q(3): What's the practical relevance of the question whether OOXML is flawed?

- A(3): Enormous. We currently see that Microsoft is trying to convince the world to accepted OOXML as an ISO "standard", whereas it's no such thing. It's too loosely defined, and opposed to the existing Opendoc standard there is no open-source reference implementation. So there will be a morass of possible implementations, of which only Microsoft's own implementations will be guaranteed mutually compatible. That's a polite way of saying that Microsoft simply aims at continuing its format lock-in, only this time the under the name of OOXML.

- Q(4) : So what's in it for Microsoft? Why do they bother?

- A(4) : Well ... Microsoft has a policy whereby it quite explicitly does not want other people's software, let alone Open Source software, to render MS Office documents correctly.

For reference, see this email, (cited from Rodriguez's article):

From: Bill Gates

Sent: Saturday, December 5 1998

To: Bob Muglia, Jon DeVann, Steven Sinofsky

Subject : Office rendering

One thing we have got to change in our strategy - allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company.

We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities.

Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows.

I would be glad to explain at a greater length.

Likewise this love of DAV in Office/Exchange is a huge problem. I would also like to make sure people understand this as well.

Is that statement of policy clear enough for you?

And now about this flawed proposed "standard": ... as soon as OOXML becomes an ISO standard, your average manager will confidently tick the box "Open standards compliant" on all Microsoft Office software. And his reasoning, reasonable and practical as ever (if a little superficial) will run as follows:

"OOXML is an ISO standard, right? And Microsoft software can read and write it, yes? If third-party vendors can't inter-operate seamlessly with OOXML documents dropped by Microsoft Office applications, then they are apparently too stupid to correctly implement the ISO standard. So lets not use their software until they can, right? In the mean time we can continue to use our MS Office software, latest version, because it's Open Standard compliant."

Hard to argue with that line of thought, isn't it?

One Question (1, Interesting)

Anonymous Coward | about 7 years ago | (#20361269)

Isn't the ISO committeee supposed to check all this before it becomes a standard? Do the test anything or just read through the spec?

Re:One Question (1, Informative)

Anonymous Coward | about 7 years ago | (#20361383)

Sort of. The Fast Track ISO process means that they trust an external standards body (in this case Ecma) to develop it to a high quality and then ISO just have to show it to the countries and get it OK'd.

Because Ecma did such a poor job and the spec is 6000+ pages it's not possible to review it in depth in the time we have.

Because ISO is an international standards organisation it's composed of national bodies rather than companies, and they need to give it their OK. There's a lot of online research to base opinions on. There's a lot of lobbying, and local tech groups who are talking to the national bodies and trying to get them to understand how OOXML is a bad standard. This has been a lot of work for me, personally. I don't like having to do this.

So it's up to the national body vote and in particular the "P" countries whose votes actually count on tech issues. Microsoft have been getting non P countries to change their status if they vote yes, in order to swing it towards yes for OOXML.

Re:One Question (0)

Anonymous Coward | about 7 years ago | (#20362131)

It doesn't matter. It will be shown, as OOXML is approved as international standard, that the ISO committee (or ECMA, or both) is a joke. No sentient being would, after fully comprehending the gargantuan specs of OOXML, ever dare calling it suitable material for international standardization. Next week, we will have proof that the ISO committee too can be either bribed or persuaded by the lies that Microsoft's lobbyists have told them. The fact that nearly every important developer (that isn't affiliated with Microsoft) that's looked at the specs has said that the design is defective doesn't matter. The fact that this specialist thoroughly debunks OOXML also doesn't matter. The fact that not even Microsoft themselves have managed to create a compliant implementation of their own flawed spec also doesn't matter. This comment, of course, also has no value, since the ISO committee will never read it.

And then they wonder why people are anti-Microsoft...

Re:One Question (0, Troll)

Carewolf (581105) | about 7 years ago | (#20363125)

No it is "design by committee". ISO or ECMA standards are not supposed to work. When they do, it is pure coincidence.

Surely this is she, or he/she (-1, Offtopic)

Anonymous Coward | about 7 years ago | (#20361277)

Surely this is she, or he/she. Stephane sound like girl name.

Re:Surely this is she, or he/she (3, Informative)

McDutchie (151611) | about 7 years ago | (#20361345)

Surely this is she, or he/she. Stephane sound like girl name.

Stéphane is a French male name. The female version is Stéphanie.

Re:Surely this is she, or he/she (0)

Anonymous Coward | about 7 years ago | (#20361643)

quite right, it's primarily a male name in French [aufeminin.com] , but sometimes used as un prénom féminin [aufeminin.com] .

Re:Surely this is she, or he/she (1)

Nicolas Roard (96016) | about 7 years ago | (#20362103)

"Sometimes" ? technically, yes, apparently (though that comes as a complete surprise to me).

But to be fair, according to aufeminin.com, the highest ever (per year) is 68 individuals while it is 23320 for the male version. 1:343 is not "sometimes" in my book, it's frigging random occurence :)

Re:Surely this is she, or he/she (0)

Anonymous Coward | about 7 years ago | (#20361797)

STEPHANIE DE MONACO!!!!

Re:Surely this is she, or he/she (1)

HeXetic (627740) | about 7 years ago | (#20362085)

... and if the grandparent still doesn't get it, Stephane is basically the French & Spanish version of "Steven".

Re:Surely this is she, or he/she (1)

phantomfive (622387) | about 7 years ago | (#20362235)

I never heard Stephane as the Spanish version of Steven, usually it's translated as Esteban; partly because 'v' and 'b' sound the same in Spanish; and also speakers of the language have a phenomenal difficulty pronouncing 'st' alone at the beginning of a word, generally pronouncing it with a leading 'e' whether it is written or not.

Re: [OT] can't reply to your journal (0)

Anonymous Coward | about 7 years ago | (#20362303)

This post in your journal is hilarious:
http://slashdot.org/comments.pl?sid=251519&cid=199 36709 [slashdot.org]

Is "Slam Dunk Networks" your competitor? :)

Re:Surely this is she, or he/she (1)

McDutchie (151611) | about 7 years ago | (#20362353)

... and if the grandparent still doesn't get it, Stephane is basically the French & Spanish version of "Steven".

That's half right. The Spanish version is Esteban. For many more national variants, see: http://en.wikipedia.org/wiki/Steven [wikipedia.org] .

So yeah, Stéphane Rodriguez has a French first name and a Spanish last name.

Re:Surely this is she, or he/she (0)

Anonymous Coward | about 7 years ago | (#20361645)

Stephane sound like girl name.

AC sound like caveman.

Personally.. (5, Interesting)

nrgy (835451) | about 7 years ago | (#20361391)

Personally I like this link [slated.org] (pdf) in the ariticle.

From: Bill Gates
Sent: Saturday, December 5 1998
To: Bob Muglia, Jon DeVann, Steven Sinofsky
Subject : Office rendering

One thing we have got to change in our strategy - allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company.

We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities.

Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows.

I would be glad to explain at a greater length.

Likewise this love of DAV in Office/Exchange is a huge problem. I would also like to make sure people understand this as well.

I'm not saying this as some linux nut job but its things like that which just drive me nuts. Regardless of which ever os I prefer that kind of thinking just boils my blood.

How can any committee deciding on open standards seriously take a company which has been proven time and time again to play by its own rules and whenever it offers something labeled OPEN its about as open as the doors to Fort Knock are to the average person.

Re:Personally.. (0, Troll)

Anonymous Coward | about 7 years ago | (#20361435)

Sent: Saturday, December 5 1998

Man, you're worse than my girlfriend for bringing up the past.

That mail is about 9 years old. I bet you've never changed your opinion about anything in the last 9 nine years and are exactly the same person after all this time. Next you'll be telling me that Linux is so rock-solid when compared to Windows 98.

Re:Personally.. (1)

ozmanjusri (601766) | about 7 years ago | (#20361573)

I bet you've never changed your opinion about anything in the last 9 nine years

Can you show us any evidence Bill Gates has changed his mind on this in the past nine years?

Re:Personally.. (0)

Anonymous Coward | about 7 years ago | (#20362109)

Can you show us any evidence he hasn't?

Also important to note, Bill Gates isn't running MS anymore.

Re:Personally.. (3, Insightful)

Tony (765) | about 7 years ago | (#20362269)

Can you show us any evidence he hasn't?

Yes.

Didn't you read the original article? Haven't you been following the OOXML story at all? There is every evidence that Microsoft has not changed, and works hard to pervert standards and processes to favor their platform over any other. Not just here, but in other areas, as well. Name one major Microsoft product that follows open, published standards without proprietary deviation. Just one. I dare you.

Also important to note, Bill Gates isn't running MS anymore.

No. Ballmer is. Bill Gates is a very smart guy (in business, at least). Ballmer is vicious, and even more cold-blooded than Gates (if that can be possible). And the corporation idolizes Gates. His influence will remain long after he's completely retired from the company.

Re:Personally.. (2, Informative)

Luctius (931144) | about 7 years ago | (#20364381)

notepad ;) best program microsoft ever made

Re:Personally.. (0)

Anonymous Coward | about 7 years ago | (#20364405)

Notepad only supports Windows-style line-endings. I dunno if that counts, though.

Re:Personally.. (1)

lordtoran (1063300) | about 7 years ago | (#20362925)

Also important to note, Bill Gates isn't running MS anymore.
I wish he still would. Just look at his successor.

Re:Personally.. (1)

CaptainZapp (182233) | about 7 years ago | (#20362821)

I bet you've never changed your opinion about anything in the last 9 nine years and are exactly the same person after all this time.

Why, of course, I reserve the right to change my opinion on a daily basis, or as Konrad Adenauer put it Was interessiert mich mein Geschwätz von gestern? (English translation) [wikiquote.org]

Microsoft Corporation unfortunately has done absolutely nothing in the past 9 years that made me rethink my opinion about them.

Hint: Calling Linux and the general public license a cancer doesn't help.

Re:Personally.. (1)

dpilot (134227) | about 7 years ago | (#20361451)

>How can any committee deciding on open standards seriously take a company which has been
>proven time and time again to play by its own rules and whenever it offers something labeled
>OPEN its about as open as the doors to Fort Knock are to the average person.

Plain and simple, arm twisting and blackmail, though both are no doubt couched in far more polite and legal-sounding terms. Microsoft-apology has become the dominant counter-culture on Slashdot of recent. But the fact remains that in spite of the fact that they may have good people, Microsoft's business conduct has been and remains abhorrent.

Re:Personally.. (1)

Sweetshark (696449) | about 7 years ago | (#20361457)

Yeah, that mails explains want Sharepoint is really for - and why it is part of the Office line.

ODF specifies ASCII number IEEE float value? (1)

Mathinker (909784) | about 7 years ago | (#20361421)

I don't believe OOXML should be a standard, but it seems to me to be pretty nit-picking to complain that numeric values are stored with "rounding errors" since that is inherent in converting between ASCII values and any binary format, including IEEE-standard floats. How does ODF handle this? It explicitly defines how the conversions are to be done? Or it caches the string the user typed?

Other than that, most of the other stuff he talks about is rather damning.

Re:ODF specifies ASCII number IEEE float value? (4, Informative)

The New Andy (873493) | about 7 years ago | (#20361625)

The relevant code from an ODF spreadsheet:

<table:table-row table:style-name="ro1">
<table:table-cell/>
&#8722;
        <table:table-cell office:value-type="float" office:value="123456.123456789">
<text:p>123456.12</text:p>
</table:table-cell>
</table:table-row>

Reasonable and Sane? Not from M$. (2, Interesting)

twitter (104583) | about 7 years ago | (#20362965)

Separating the value and the display solves the problem. As long as the value stored is preserved, other programs can work with it without introducing arbitrary changes. That M$ does not store the exact value and relies on the reader to make the same rounding error is crazy. It's a trap for every system that is not M$, and might not even work across different processors for M$.

I've run into this problem in my own work, where it did not matter. A data acquisition system I used required Winblows. It could write to either text or some nasty binary format. I chose text with a sufficient number of digits to avoid the binary conversion. This blew up my file size, but made it easy to read. In my case, the extra digits were noise anyway and it only gets read once by other programs. In a bank this clearly would not work. In a place where the values must be read and saved multiple times, this would not work. As a programmer, I'm a relative zero but even I can see how broken the M$ way is.

Value storage was only the beginning of OOXML problems. The formula and binary inclusions are even worse. Hopefully, ISO will reject this mess.

Re:ODF specifies ASCII number IEEE float value? (2, Interesting)

putaro (235078) | about 7 years ago | (#20361721)

No, this is a pretty reasonable thing to point out. It wasn't a value that was undisplayed. When you look at the cell it shows it (in decimal) as 1234.1234 (without the cell rounding). So it shows you that on the screen but doesn't store it properly in the XML file. I would say it's a problem. If it were stored as a binary floating point number in the XML I'd say you might have a point, but if it's displayed on the screen in decimal and then the decimal value in the file is different, that's pretty broken. And it's not just broken, it's now damned hard to work with. What happens if you pull the value from Excel using VBA and then try to change a value in the XML? They're not going to be the same.

Re:ODF specifies ASCII number IEEE float value? (0)

Anonymous Coward | about 7 years ago | (#20361967)

And you don't know a fucking thing about floating point numbers. Try reading about how they work before bitching about differences that don't actually exist.

Re:ODF specifies ASCII number IEEE float value? (3, Informative)

putaro (235078) | about 7 years ago | (#20362493)

Oh, I just love being schooled by AC's who don't know what they're talking about.

So, there are numbers that floating point formats do not represent well. However, the world is not floating point numbers. And computer math is not just floating point numbers.

The number is stored in the XML as an ASCII represented decimal real number. They're not stored as binary floating point numbers and they shouldn't have the kind of brain damageness that floating point has.

Let's look at what's going on here.

User enters a number in a decimal format. User sees the number in a decimal format displayed on the screen. Excel apparently does not use floating point or it's got a lot of compensation because if you do things like multiple 12345.12345 * 100000000 you get 1234512345000 and not some weird approximation. I would guess that the XML output routine is using floating point (and why would be a good question).

Why is this a problem? Well, we don't know how many digits of precision to work with here or how to round things. If I write an app to work with the spreadsheet I'd probably use something like a Java BigDecimal to handle the numbers. But, I don't know how to round things out so that I get the right numbers. If I use a BigDecimal, 12345.123449999999 is going to be 12345.123449999999. If I multiple by 100000000 I will get 123451234499.99999 instead of 1234512345000 as I would expect from looking at the values that were put into the spreadsheet.

Excel should be putting the proper values out in the XML or the standard should define the form of rounding/conversion to be applied.

Re:ODF specifies ASCII number IEEE float value? (2, Interesting)

Estanislao Martnez (203477) | about 7 years ago | (#20364361)

I agree with all that, but I think you're missing something very fundamental: the purpose of a document format is to encode what the user did and what it means. This is the reason why the details of binary floating point arithmetic are irrelevant in this context, and their use in the file a flaw: if the user typed "1234.1234" in the document, the user meant 1234.1234, and the file better guarantee me, author of a program that reads it, that I can find out for sure that the user meant 1234.1234. The trivial way to do that, of course, is to store precisely what the user is shown on the screen, because it is the thing that the user manipulates until it looks right to them, i.e., until they judge that the thing that they see in the screen is what they mean.

This doesn't apply just in spreadsheets, of course; it applies everywhere.

Re:ODF specifies ASCII number IEEE float value? (0)

Anonymous Coward | about 7 years ago | (#20362591)

The point is, those values have to be stored in the form in which they were entered. Rounding errors are intolerable when a formula that treats the number as text might be used (which is not uncommon when doing sorts and lookups).

If I construct a spreadsheet in Excel that uses text(), concatenate(), and similar formulas, and I save it as a .xls and again in OOXML, I should be able to open the OOXML in any spreadsheet application that understands OOXML and all the cells would be identical with the .xls version.

But if TFA is true, even if I open the OOXML file with the Excel that created it, I will find that the values of the formulas that rely on text conversion will be different from the .xls version. Saving in OOXML of itself has corrupted the spreadsheet.

The speed with which Microsoft has developed OOXML, the volume of documentation that is used to describe it, and Microsoft's powerful efforts to keep it on a very fast track for adoption, with none of the usual revision processes, taken together strongly suggest that Microsoft is attempting to make a standard that won't work. That MS Office products fail in basic ways to meet this proposed standard is strong supporting evidence that Microsoft has designed OOXML to fail. That it is "defective by design" in every meaning of that phrase.

Re:ODF specifies ASCII number IEEE float value? (1)

jbengt (874751) | about 7 years ago | (#20362691)

When you use MSExcel, you type in decimal numbers, represented by ASCII (ANSI?) characters.
You expect to get that stored exactly in the ANSI characters of the XML file.

And you can store IEEE floating point numbers exactly using ASCII characters.
(after all, you can code binary as a series of ASCII "0"s and "1"s)

Re:ODF specifies ASCII number IEEE float value? (1)

Ilmarin77 (964467) | about 7 years ago | (#20363149)

Imagine this happening to some accounting software...

Can anyone repro? (2, Interesting)

figleaf (672550) | about 7 years ago | (#20361433)

I tried to repeat the cell changes experiment but I do not see the Excel error.

I bet Mr. Stephane is not saving the sheel xml in utf-8.
The header of the xml file says its utf-8, but he might be saving it without the UTF-8 BOM header.

Re:Can anyone repro? (3, Funny)

gardyloo (512791) | about 7 years ago | (#20361583)

Interesting experiment. However, I suggest you do not title your posts "Can anyone repro?" on Slashdot. The answers you get may be, well, .... exciting and very, very scary.

Re:Can anyone repro? (3, Informative)

YA_Python_dev (885173) | about 7 years ago | (#20362049)

The header of the xml file says its utf-8, but he might be saving it without the UTF-8 BOM header.

So? It's still perfectly valid XML even without the BOM. XML it's a real standard and I suggest you read it, it's not Notepad.

And don't even start talking about malformed UTF-8 since he only used characters in the ASCII subset, so even saving it as Latin-1 would have generated valid XML.

Re:Can anyone repro? (4, Insightful)

Karellen (104380) | about 7 years ago | (#20362113)

Uh, UTF-8 files do not need a BOM. What the fuck is the point of a byte-order-mark on an encoding that is byte-order neutral?

One of the advantages of UTF-8 for text files is that you don't need a BOM. With XML it's even easier because, as you point out, the XML declaration ("XMLDecl" in the spec) header can contain the "EncodingDecl" to tell explicitly you the file is in UTF-8. If the EncodingDecl says UTF-8, and the file is encoded in UTF-8, then if an XML parser cannot handle that, it's seriously fucked an needs to be fixed.

You might also want to go read STD-63 at some point. It points out that there are a few problems with using BOMs in UTF-8, and that if there is a way for UTF-8 to be determined in a way other than with the use of a BOM, that should be used instead. Given that XML specifically includes support for an "EncodingDecl" in the "XMLDecl", it is clear that best practices dictate that you *shouldn't* use a BOM when working with UTF-8 encoded XML files. Even if your tools _insist_ on writing BOMs to such files, they had *better* still be able to work if the BOM is missing.

Heck, with OOXML, you could also use the ZIP's manifest file to keep track of file metadata like the character encoding.

Re:Can anyone repro? (0)

Anonymous Coward | about 7 years ago | (#20363089)

Karellen said UTF-8 doesn't need BOM and explained quite well why. I'll put it even stronger: BOM in UTF-8 is *plain wrong*

One of the nice things of UTF-8 is that it's upwards-compatible to ASCII. This stupid BOM *breaks* that, by inserting two non-ASCII characters at the beginning of each file.

I know, I know. Microsoft does it. Stupidity or malice?

How about an email campaign to your ISO reps? (0)

Anonymous Coward | about 7 years ago | (#20361485)

How about everyone in /. email the people from your country and get all your friends to warn them about all the technical problems in the proposed standard!

http://www.iso.org/iso/en/aboutiso/isomembers/Memb erCountryList.MemberCountryList/ [iso.org]

Re:How about an email campaign to your ISO reps? (1)

janrinok (846318) | about 7 years ago | (#20361731)

"Sorry, the URL you have requested does not exist on this server."

Hardly looks like the /. effect.

Defective by Design (1)

jollyreaper (513215) | about 7 years ago | (#20361693)

Well, I suppose that's an improvement over Vista, "defective by nature." I can just imagine Bill Gates stamping his foot and crying. "Defective? I meant to do that!"

Rounding errors (0)

Anonymous Coward | about 7 years ago | (#20361709)

The rounding errors given by the author in section 2 are wrong:

    12345.12345 12345.123449999999 o(1e-5)

The rounding error is 0.000000000001 = 1e-12

Thought, the overall remark remains valid: The value should (also) be saved exactly as it was entered.

     

The fractional part is in great error (0)

Anonymous Coward | about 7 years ago | (#20362135)

That is all she is refering not whole

ISO Credibility (1, Insightful)

Anonymous Coward | about 7 years ago | (#20361841)

We all clearly benefit from international open standards. It's also clear that a central coordinating authority like ISO can expedite widespread adoption of such standards by virtue of being even-handed impartial experts on such matters. However, when ISO starts publishing so-called "standards" that are nothing more than paid-for advertising, the credibility of everything they do is called into question. If ISO is unable to withstand political and financial pressure, and we can no longer depend on them to impartially adjudicate the standards making process, then ISO has become irrelevant, at least as far as the IT industry is concerned. The ISO directors have a choice: they can either be paid shills, or a respected standards body - but not both.

Stephane is just after the money... (0)

Anonymous Coward | about 7 years ago | (#20361857)

Stephane has been trying hard to win his 2,500 euros throughout this process, I'm guessing that this is just his final shot at winning the prize.

http://www.noooxml.org/kayak/ [noooxml.org]

Some Points Are Valid, Others Not (2, Insightful)

SwashbucklingCowboy (727629) | about 7 years ago | (#20361871)

For example, the part about "Entered versus stored values" is certainly valid (though I wonder if that's not a problem with Excel itself, and not the format). The complaint about the date format is also on the money.

However, other things seem either wrong or have a bias towards hand editing of the files, e.g. "International, but US English first and foremost". He complains that it uses U.S. English settings. He may not like the U.S., but it's called picking a canonicalized format. Consider the alternative for implementing this in software, parsing of the values in the XML would now depend on settings also found in the XML. That would be insane.

Re:Some Points Are Valid, Others Not (2, Insightful)

kabz (770151) | about 7 years ago | (#20361945)

He may not like the U.S., but it's called picking a canonicalized format. Consider the alternative for implementing this in software, parsing of the values in the XML would now depend on settings also found in the XML. That would be insane.
Here's a reference to XML DTDs [w3schools.com] . This is exactly what should be used to defining localized formula names etc. With XML, you might not be able to do much with it, but given a 'real', properly defined XML format, it should at *least* be possible to parse all the information in the damn thing!!

Why use a DTD?

XML provides an application independent way of sharing data. With a DTD, independent groups of people can agree to use a common DTD for interchanging data. Your application can use a standard DTD to verify that data that you receive from the outside world is valid. You can also use a DTD to verify your own data.

A lot of forums are emerging to define standard DTDs for almost everything in the areas of data exchange. Take a look at: CommerceNet's XML exchange and http://www.schema.net./ [www.schema.net]
Where is a DTD referenced? That's right, at the top of the XML file.

Foresight (3, Informative)

akaiONE (467100) | about 7 years ago | (#20362489)

"..Next week members of the International Standard Organization are likely to approve the format as a second official ISO standard for office documents.."

Err.. Next week news called, they want their draft story back.

There is no certain outcome of next weeks vote; and the fact that we even are discussing the defects of OOXML are proof that the ISO body will have much problems just waiving this through. Please refrain from taking sides just because this is an 'Microsoft-standard'.

I'd say it's possible that OOXML will NOT be approved next week. It will probably have to take the long road through the ISO as a real standard proposal, not just a fast-tracked 6000 page gorilla.

Did you check Groklaw lately? (1)

scsirob (246572) | about 7 years ago | (#20364291)

Microsoft is manipulating many members of the ISO technical committee into voting 'yes', and even rigging the voting process in several countries.

The voting process is 'defective by design' as votes from each country must be unanimous. Microsoft is a member in most (if not all) countries and will always vote 'yes'. This means that the vote can only be 'yes' or (when no unanimous vote can be reached) 'abstain'. All other votes will be declared invalid, and only the 'yes' votes count. Still believe the outcome will be no?!?

Call me a cynic (2, Insightful)

PinkyGigglebrain (730753) | about 7 years ago | (#20362577)

I already know how this is going to turn out.

OOXML will be voted in as an ISO standard.

Third party vender's trying to implement the "standard" will waste time, money and effort and accomplish nothing of import.

MS will continue as normal, claiming support for open standards while locking anyone they can into formats/software they own.

ODF will continue as a marginalized format used by people on the "fringe".

item #1 seems a bit ridiculous (1)

harlows_monkeys (106428) | about 7 years ago | (#20362739)

What his first item seems to come down to, when you put all the parts together, is that if you want to change data in a spreadsheet that contains formulas that reference other cells, you have to write a program that understands spreadsheets that contain formulas that reference other cells, so you can make sure to update the reference and dependency information.

Well, duh!

Re:item #1 seems a bit ridiculous (1)

try_anything (880404) | about 7 years ago | (#20364269)

Exactly. He ignored the spec, made whatever changes seemed okay to him, and produced a non-standards-conforming document. With that kind of "I don't have time to read the spec" attitude you have to wonder how he came to care about international standards at all. It's actually a *good thing* (in the long run) for programs to reject clearly nonconformant documents instead of attempting to render them.

Some of his other points look good, though, and in any case, it just strains credulity that Microsoft would do something as disastrous as enabling interoperability with Office. Asking me to believe that Microsoft is making a good-faith effort at losing billions of dollars is like asking me to believe that water flows uphill.

In the words of Gaz: WHINER (0)

Anonymous Coward | about 7 years ago | (#20362831)

There was a lot of whining about MS formats not being open, so MS throws everyone a bone. For the most part, Excel does in fact follow the standard, because the standard is BASED ON EXCEL. Everybody knows that there's years of cruft in Excel. Why would you expect anything different?

If you want interoperability between spreadsheet packages, then its up to each spreadsheet implementor to replicate all of those nastry rules, not the end users. Hell, if they've done an xls format conversion, they're probably half way there. The difference is that the open format is well, open (supposedly).

If you want to read values from an OOXML spreadsheet, then it looks like it works just find, barring the wack rounding errors. If you want to write Excel files, and you're not an implementor, it would be simpler to just buy the doggone software and use .NET to do it. It's a business need, right? You may even be able to get away with grabbing Open Office and doing the same when they get their implementation going.

P.S. Invader Zim ROCKS

seriously my misguided foss friends... (1)

can.i.have.free.beer (1141057) | about 7 years ago | (#20363601)


If you want to beat Microsoft at the Office game, build a better word processor. All this non sense over document formats is just a weak attempt by FOSS to compete through legislation where you fail to compete on merit.

Get off your ass and turn Open Office into something sexy that looks, feels and runs on par with Microsoft Office and then let the market decide. You have google behind you. You have IBM behind you.

BTW. I use Office 2007. I think Open Office is garbage compared to MS Office. I don't use the OOXML document formats as most people in the business world need the old format.

Except he doesnt. (3, Informative)

miguel (7116) | about 7 years ago | (#20363627)

Stephane has for a long time presented a weak case against OpenOffice XML.

"1) Self-exploding spreadsheets"

His top issue "1) Self-exploding spreadsheets" has been discussed on Brian Jones' weblog:

http://blogs.msdn.com/brian_jones/archive/2007/08/ 15/why-there-s-no-microsoft-in-open-xml.aspx [msdn.com]

It boils down to: the fact that is XML does not mean that you can modify it in any way you want; There are rules for modifying the schema and Mr Stephane is not happy with that. Had he followed the actual rules he would have had no issue.

This is a case where two locations must be updated per the spec; He can avoid updating the two locations by removing the chainCalc.xml file (which is optional, and Excel will reconstruct). He later gets upset because if he does that, he claims performance on load will be slower.

"2) Entered versus stored values"

His second point in "2) Entered versus stored values" in an interesting distinction between entered values and stored values. It reflects the way that Excel works (and so does Gnumeric) by storing the values instead of the data that was entered by the user. This responds to the need of the spreadsheet to do something interesting with the data, for example when you enter a date, it is stored as a number with a format applied not as a string. This allows computations on dates to happen based on the underlying numeric value. The featured is used extensively by spreadsheets.

In the Excel/gnumeric case you have to generate a single value, in the ODF case you must generate and update the two values (which just a point before, Stephane was having a seizure about).

The precision issue that he brings up, I suspect is merely an issue with double format precision. He claims that the data is unusable and there is a loss of precision, but handing that out to a C compiler will produce the expected result with no loss of precision. I do not know how "atof" or the compiler work internally to cope with this issue, but at least my libc/gcc combo does not have this problem.

I would not be surprised if this is an artifact of floating point, someone with more background on doubles and floating point math could probably answer the question with more authority, but a cursory read of "What Every Computer Scientist Should Know about Floating Point" seems to validate that there is no error in the floating point representation for the values that he uses: http://docs.sun.com/source/806-3568/ncg_goldberg.h tml [sun.com]

3) Optimization artefacts become a feature instead of an embarrasment

His 3rd point is open for debate, like the 1st case, we have a case where he has to handle things differently. Stephane sells a commercial product to handle Excel files and I suspect that his product has to cope with the same patterns in different ways, which has naturally upset him. OOXML might be inspired by Excel's needs, but it does not mean that it has to be a 1-to-1 match.

4) VML isn't XML

VML is labeled as "deprecated" in the OOXML documentation (Section 8.6.2, page 25) and it states: "The VML format is a legacy format originally introduced with Office 2000 and is included and fully defined in this Standard for backwards compatibility reasons. The DrawingML format is a newer and richer format created with the goal of eventually replacing any uses of VML in the Office Open XML formats. VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML."

So the standard basically says "VML is still in use, but its better to use DrawingML". Stephane misconstrues the above statement and tries to portray this as evil (quotes a 1998 memo from Bill Gates) and tries to illustrate that VML is still in use.

The spec did not claim it was not in use, and that was the reason that it fully documented the VML.

In addition, Stephane claims that VML is not "XML" because it contains stuff like:

path="m,l,21600r21600,l21600,xe"

Inside an XML element. He says, "contradict proper XML design.", except that the above is very similar to how SVG encodes paths as well. It is basically a balance between a more bloated-markup and a more compact representation.

5) Open packaging parts minefield

I do not have a strong opinion on this. Other than being a nuisance for people that modify existing files (as opposed to generating them) it does not seem to have much weight, I might be wrong, but I do not know enough about the pros and cons of each approach.

6) International, but US English first and foremost

In the first half of this section, the complaint is that the data is stored in a US-centric way and that applications have to cope with this.

This is correct, but it also simplifies all applications, because to interoperate with the file format, you do not have to test your code with every possible language supported. If you support the US locale you can generate documents that will render properly and with the user settings everywhere in the world.

This means that you store stuff like "123.456" for the number 123 with decimal value 456, this is the "US centric" storage that he refers to. This value is easy to generate and parse back with pretty much every API in the world. At render time, the spreadsheet must turn the value 123 with decimal value 456 into something that is adequate for the current locale. In some locales that will be the string "123.456" in others "123,456" (point vs comma).

The same applies to formulas. You must store formulas in English, instead of your native languages. This is --once again-- a sound engineering decision. This means people writing parsers only have to parse "SIN(X)" instead of having to support every possible language in the world in order to parse OpenXML document.

Imagine trying to parse a spreadsheet that encoded the values in Spanish, French, German, Hebrew, Tamil, and so on?

In my opinion, this is a sound decision: internally store the data in one format, and at presentation time localize it.

In fact, this is *exactly* what we do in every Linux package: we develop it in English, the strings are hardcoded in English, the values are hardcoded in English, C programs use the US notation for numbers and at runtime we translate those values and render those values into the proper locales.

7) Many ways to get in trouble

Not really worth getting into it. A cell format is affected by various elements, and it must be taken into account. This is both an optimization for the spreadsheet itself at runtime, as well as an optimization for file size, and load time.

It is one of those knobs, and you could argue which way you prefer (no sharing, but more work and more memory usage, or sharing that requires more markup, but reduces memory usage and load times).

8) Windows dates

Here Stephane gets confused again.

He brings into the discussion an OLE API that has nothing to do with Excel. Probably because when you use COM from VisualBasic you have to go through those functions and this is probably what you would use to "talk to" remotely to Excel. But this has little to do with Excel's date formatting.

Stephane quotes the OLE documentation, where it says "The value 2.0 represents January 1, 1900", but this is different than the Excel and the OOXML behavior (for compatibility reasons, the famous DATE issue). In Excel the value "2.0" reprensents January 2nd.

His entire argument here is based on the flawed assumption that Excel uses that COM routine to do its date manipulation. But Excel date support predated OLE.

He also claims that the number formats are "undocumented patterns" in that very section, when talking about the following number format:

formatCode="[$-40C][Red][>120]_-* #,##0.00\ _F_-;\-* #,##0.00\ _F_-;_-* "-"??\ _F_-;_-@_-"

That is odd, because I remember implementing the support for this in Gnumeric many years ago, and at the time I used the Excel reference, it would be odd if this was not specified.

And lo and behold what do we find in the OOXML spec? section 3.8.31 "Number Formats" (page 2134) in the SpreadhseetML that fully documents those formats. I cheated though, I used the Adobe Acrobat "Find" function, which Stephane might not be aware of.

9) All roads lead to Office 2007

Am not sure I understand this argument, but apparently if you use Excel to open and save files it reshuffles things around. This is of course a criticism that should be aimed at the implementation, it is not really a criticism of the OOXML file format.

I do not know if there is a good reason or not for this in Excel, and I do not know what OOo or Gnumeric will do, but it seems that this is complaining about an implementation.

He might have a point here, but I would not get my panties and leave over this.

10) A world of ZIP+OLE files

This seems like another problem with Excel, not with OOXML.

When encrypting Excel stores files in the old OLE2 format, I agree that this is suboptimal. Stephane makes his first valid point, I must applaud him.

11) BIFF is gone...not!

This is not really a problem with OOXML, so am not sure what its doing in a document titled "Microsoft Office XML formats? Defective by design".

It is a valid criticism of the binary file format used by Excel: the new version has not been documented; But that has nothing to do with OOXML. This is just padding.

12) Document backwards compatibility subject to neutrino radioactivity

Stephane shows that Excel has a bug in its import capabilities.

And contrasts this with the stated goal of MS with respects to OOXML: that they designed a format for high-fidelity and claims that since there is clearly a bug (and there is clearly a bug) that Microsoft's goal of high fidelity is a ruse.

I guess that Stephane is a better programmer than I am, because if the process of building software has taught me one thing is to be humbler when criticizing other people's code. Its like the Jesus quote, "the one that is free of sin, should throw the first rock" or something like that. I just do not feel like lecturing others about the quality of their code, when I know that I make so many more mistakes.

Anyways, here I believe most people will disagree with me, that is fine.

13) ECMA 376 documents just do not exist

Stephane has one valid point (DRM, Encryption and embedding of non-standard components like ActiveX controls) can make your document non-ECMA compliant. To be fair, those are corner cases.

Then he makes another two points: one based on a conspiracy theory, and one based on his faulty logic that he presents in the article to claim that ECMA 376 documents do not exist.

In my opinion, his conclusion is as solid as Powell's "facts" on Iraq at the UN.

You can see a "mobile biological weapons lab" on every Falafel truck in Iraq if you want, and you can find a defect on OOXML for every feature that you do not understand or do not want to bothered to understand.

Miguel.

It'd help his case a lot... (0, Troll)

petrus4 (213815) | about 7 years ago | (#20363953)

...if he didn't use such emotive terms as "exploding," and "minefield." It really doesn't help him sound objective when the topic he's talking about is file formats for office software, rather than undetonated mines which is what, from that wording, you might be expecting him to be talking about with such language.

Of course, it's no accident that he doesn't sound objective...it's because he isn't. I have no problem whatsoever believing that Microsoft's file standard proposals are more than likely harmful, given their track record, but I'd prefer to read an account of such from someone who doesn't sound quite so strongly like a full member of the cult of Richard Stallman.

One other thing I really wish FSF cultists could do is actually come up with your own terminology for things, rather than simply parroting your leader's loaded language ad nauseum.

If, as people have said, it's "disingenuous" of me to refer to the FSF as a cult, then maybe it's also equally disingenuous of the group's supporters to keep acting so much like cult members. You know the old saying...

"If it walks like a duck, and quacks like a duck..."
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>