ISO Approves OOXML 435
sTeF writes in, with the hope that this is an April Fools joke. Doesn't look like it though. An article up at Intellectual Property Watch claims they have obtained a document (PDF) enumerating the vote after Microsoft's OOXML won ISO standard status.
Do they not know their own rules? (Score:5, Informative)
However, how valid are those votes? For example, the ISO/IEC JTC1 directives seem to pretty explicitly forbid changing the vote from "disapprove" to "abstain" like AFNOR (the French standardization organization) did [adaptux.com] (under the influence of heavy lobbying from Microsoft and HP [groklaw.net]).
Re:ISO death bell (Score:2, Informative)
Re:pyhrric (Score:5, Informative)
Here are two reports on OOXML that I recently released, one (PDF, 0.9MB) [iso-vote.com] and two (PDF, 0.8MB) [iso-vote.com].
Fix the headline, please (Score:3, Informative)
Microsoft buys ISO certification; World looks on with drool on its face
Re:pyhrric (Score:2, Informative)
So it's the same old story about reverse engineering Microsoft Office, not implementing a poorly defined inconsistent "standard".
Re:ISO death bell (Score:1, Informative)
Re:I need enlightenment... (Score:5, Informative)
From user's point of view, this rushed standardisation means that the whole point of the standardisation has been defeated in OOXML's case. It also means that we now have two standards that solve the exact same problem, and thanks to the Marketing, the technically far worse format has a chance at winning: If OOXML becomes the dominant format, the promising future from OpenDocument may not be realised. It can be a major setback.
And what was the point of the standardisation? What was the golden promise of OpenDocument? Interoperability, plain and simple.
Simply put: In the current state of affairs, OpenDocument is implementable by third parties. OOXML is not. There can and will be many OpenDocument applications. If OOXML won't get fixed, there will be one and only one application with anywhere near compliant OOXML support.
With OpenDocument, you can edit the documents in any ODF-compliant application - or process them with any external tool, or generate them from scratch programmatically - and there's no problems because the standards is complete, well specified, and not hopelessly tied to one application. OOXML, in comparison, has nothing of this: There's a bunch of nasty features that make writing completely compliant applications difficult, if not impossible. The end result will be that there's one application that processes OOXML "perfectly" (MSOffice) and the rest work when they work (and since consumers expect perfect behaviour, it means they aren't used very much, no?)...
Sure, the interoperability dream is still very much there, because ODF is still out there. It's just that now we have a completely redundant standard that is a) technically inferior but b) Microsoft will make you either use it, or cry and use it.
Approval was not won... (Score:4, Informative)
Approval was not won, approval was purchased.
Re:I need enlightenment... (Score:5, Informative)
That's pretty much because:
a) the voting irregularities are IMMENSE
and
b) there is no review on OOXML from the user's standpoint, because there is NO implementation (ZIP, ZERO, NONE) of the ISO candidate version of OOXML to review. Not even from Microsoft, who are using a different version now, and (IIRC) have stated that they WILL NOT be using the ISO version in the future, if it is approved. AND it is likely that there will never be a complete 3rd party implementation of the ISO OOXML standard because it is so long, complex and dependent on patents and references to legacy closed source software. MS happens to own that source and those patents and aren't about to give them away. So basically it's a dead end mockery of the ISO process.
If that's not enough to answer your questions AND piss you off, do some more reading on the topic.
Try reading up on how and for what the Fast-track process has been used in the past: Mature, complete and currently implemented industry standards that are just being formalized; Not slap-dick, fly-by-night, throw-in-kitchen-sink 6000 page cluster-f*ks like OOXML.
Re:pyhrric (Score:2, Informative)
It would be a lock-in tactic, and open-source software isn't really capable of that: If there was demand for OOXML import/export, and Sun didn't implement it, someone else would write an extension for it anyway (or worse, fork the whole project). If organizations are going to ask for OOXML support (if only to handle the stray
Re:Stop crying, people. Start being HONEST. (Score:4, Informative)
around 1.5% of them have been adressed in the meantime
what non-bribed ISO member would say now "wow, they adressed so many complaints that I can go from a 'no' vote to a 'yes' vote"?
Re:Good Luck. (Score:1, Informative)
Of course the only sensible way to judge a framework is by its install time, right? Or by insinuating that it comes from furriners?
Re:Why is this bad? (Score:4, Informative)
Unfortunately, it is true. (Score:2, Informative)
http://www.iso.org/iso/pressrelease.htm?refid=Ref1123 [iso.org]
Pathetic, if you ask me.
Re:Support Needed. (Score:3, Informative)
Re:Stop crying, people. Start being HONEST. (Score:4, Informative)
- The ISO members (the JTC1 committee) found 3522 defects in the OOXML standard
- The Ecma grouped these complaints and proposed 1027 changes on about 2300 pages
- Microsoft said they had adressed 662 of the proposals
- At the isos ballot resolution meeting (BRM) 900 of the 1027 proposals were not checked (they didn't check if MS had implemented the changes)
- Rob Weir used a random sampling technique to estimate how many proposals were actually implemented: about 1.5%
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9065903&intsrc=news_list [computerworld.com]http://www.pro-linux.de/news/2008/12520.html [pro-linux.de] (german)
http://politics.slashdot.org/article.pl?sid=07/12/04/0310208 [slashdot.org]
http://www.robweir.com/blog/2008/03/how-many-defects-remain-in-ooxml.html [robweir.com]
Re:pyhrric (Score:3, Informative)
I don't mean to sound like format correctness Nazi, but your PDFs could be much, much smaller.
You just need to substitute the Nimbus family of fonts (which are in Type 1 format) for some corresponding TTF fonts, like the FreeSans/FreeSerif families.
The problem is that OpenOffice PDF exported currently cannot do subsetting for Type 1 fonts, only for TTF fonts. So it embeds the full Type 1 fonts (Nimbus in your case) in the file. All the characters, including unused ones, like Japanese, Hindi and Chinese glyphs!
That's why your PDFs are almost 1 megabyte when in fact they could be twice as small.
Look in the properties of your PDFs (or use pdffonts utility) - when your see font names like "DAAAAA+font_name" then it's good - they are subsetted.
But font names that aren't prefixed with those "?AAAAA+" strings are embedded fully, without subsetting - they occupy lots of space!
Eliminate those fonts from your document when exporting to PDF, until OpenOffice issue 46305 [openoffice.org] is resolved (not likely in the near future...).
Re:Weirdest April 1st Ever! (Score:5, Informative)
According to ISO press release [iso.org], "Subject to there being no formal appeals from ISO/IEC national bodies in the next two months, the International Standard will accordingly proceed to publication". So there's still 2 months for appeals from NB's.
You are lying. Msft can use ODF. (Score:4, Informative)
Absolute 100% pure unadulterated crap. Msft is entirely capable, and welcome, to use ODF. In fact, I think plug-ins already exist.
I am sick to death of this brazen lie being propagated on slashdot, and elsewhere. It is not true, and it makes no sense. You statement is based on the assumption that ODF locks msft out - and that assumption is simply not true.
Re:To: central@iso.org (Score:2, Informative)