Too bad OO.o sucks in general for the market that MS Works targets.
MS Works on Windows and iWork on Mac target those that don't need the power of MS Office and OO.o, and don't want to deal with the complications of those apps. MS Works and iWork offer task-based templates to get simple tasks done quickly. MSO offers that as well, but to a lesser extent, and OO.o is woefully lacking in that sort of thing.
More likely, since Office 2007 was made by Microsoft, you're predisposed hate it so you do. If Office 2007 were made by some OSS company, you'd be hailing it as a triumph of the OSS model, and you'd be ridiculing Microsoft for being stuck in the old UI paradigm of Office 2003 and its predcessors. And both you and I know it.
How would your example of "online stores with search fields" work? Google sends millions of different search queries to the server and index es each result?
The idea of sending automating form submissions seems very spammy.
Seems kind of weird (and wrong, frankly) to force another's server to handle automated bogus form submissions.
If this were an opt-in thing, then sure, those that want the content that resides behind forms to be indexed by google could opt for that. But google is making this an opt-out thing. If the web mananger has content that is only accessible via forms, then he probably doesn't intend for that content to be indexed. Google is saying, "Well use 'nofollow' links or edit the robots.txt file or whatever" (I'm not a web dev so I know next to nothing about such things), but it still forces the webdev to go back and "fix" his site to prevent form-hidden content from being googlized, which he didn't have to do before.
OOXML would fail requirements 2 (AutoSpaceLikeWord97, VML etc.), 3 (date representations), 4 (VML vs. SVG) and 5 (the OOXML spec has no implementations in the wild; the Office 2007 format does not match the spec). I'm not sure about requirement 1, but it's possible that OOXML fail that as well. You, like most slashdotters, are completely unaware of what changes were made between ECMA's OOXML and the recently approved ISO OOXML.
First, the "AutoSpaceLikeWord97" issue has been fixed. AutoSpaceLikeWord95 and the like have now been fully spec'ed and placed in the "transition conformance" section (i.e. those behaviors are deprecated, only for use in old documents). See the AutoSpaceLikeWord95 section of this page. And see supressTopSpacingWP, for example
Second, ISO OOXML spreadsheets have only one date format, the ISO 8601 date format. And the Lotus leap year bug behavior has been deprecated, only for use by old spreadsheets (that may rely on that behavior either implicitly or even explicitly). Moreover, ISO OOXML's date format is now simpler than ODF's. Resolution of OOXML spreadsheet dates issue
Third, VML has also been deprecated, and new documents are only to use DrawingML. But you cite SVG; the thing about that is that what ODF calls "SVG" isn't actually SVG. ODF extends SVG's features, cuts lots of SVG's features, and changes the behavior of other SVG features, so that one cannot just use an SVG library to implement ODF's "SVG" functionality and call it done. Embrace and extend - SVG in ODF revisited
Finally, of course, there are not yet any ISO OOXML implementations in the wild. But there aren't any full implementations of ODF in the wild either. Here's a list of ODF apps, scored on their ODF functionality, and no app achieves a perfect score, not even OO.o. http://opendocumentfellowship.com/applications
In summary, many here talk of how horrible OOXML is by citing problems that have been resolved in the approved ISO revision. (I'm amazed that so many here are under the illusion that the problems cited with ECMA OOXML weren't addressed at all in the final ISO version. Under that misunerstanding, I can see where one might be tempted to believe that NO votes switching to YES votes could only be the result of bribery and corruption.)
Many here also are blissfully (willfully?) ignorant of ODf's own problems. I've almost NEVER seen a post, let alone an article, on ODF's problems, like its bastardization of SVG. For example, people here cite ODF's use of "SVG" as a virtue, unaware that ODF's "SVG" isn't really SVG.
The irony is that ISO now completely controls OOXML, while it does not control ODF (OASIS still does). Indeed, OASIS has made ODF 1.1 and 1.2, but hasn't bothered to submit either to ISO. (Which makes ODF 1.1 and 1.2 illegal for government use by governments that pass laws requiring ISO formats.)
The other irony that ODF was ratified by ISO, pretty much under the radar, with minimal scrutiny, while OOXML is probably the most scrutinized ISO standard ever. Yet the common belief around here is that OOXML was rushed through the ISO process. If any format was "rushed" through ISO, it was ODF. ODF 1.0 lacks major functionality (the most famous of which is support for spreadsheet formulas) and is essentially a 0.8ish format (rather than a 1.0 format). But this incomplete format was rushed through ISO, for the sole purpose of saying, "We are the first to get ISO's stamp, so our format is not just A standard, but THE standard, and ISO should reject all other standards in the future so that ODF rules forall time!" OOXML, on the other hand, slogged through a highly scrutinized process that resulted in an improvement over the ECMA OOXML 1.0, to a format more akin to a 1.5 format than a 1.0 format.
So, as things stand now, OOXML is more "open" (in that ISO controls it, unlike ODF) and more advanced (due to the high scrutiny that resulted in improvements (ISO's rush job on ODF didn't improve the format at all over what OASIS submitted).
You guys need to step back and see things for what they are.
Sadly, much of what you say applies to OO.o and ODF. OO.o's files aren't in full compliance with ISO ODF (and therefore OO.o's ODF can be differentiated from ISO ODF), and different apps exhibit different behaviors when reading ODF documents. Indeed, many ODF apps are "second-class" ODF apps.
You'll note that NO app achieves 5 stars. There are a number of 4-star apps, but most are three stars and lower. (And I'd bet you a twinkie that nearly all (and possibly ALL) of the 4-star apps aren't independently developed from the spec, but are using rebranded versiond of OO.o's code. (It's known that many ODF apps are simply using OO.o code (the ODF spec is too vague in many places to create code simply based on the spec.)
(There's another web page on an ODF support site somewhere that lists details of problems when using particular apps to load ODF files created by other particlar apps (like using K-Office to load ODF files created by OO.o), but I can't find it at the moment.)
Baseless accusations of bribery, et al, might be considered personal attacks by those on the receiving end.
The problem is that your accusations of bribery, et al, are so vague, that you're painting everyone that voted YES with the "corruption" brush. I wish you guys would man up and make a specific corruption charge against specific individuals.
Well, according to you guys, nobody in his right mind would switch from NO to YES without being bribed (or whatever), so let's get specific. Are you accusing Jiri Kosek of accepting a bribe, yes or no?
Sure, it's easy to accuse Microsoft of bribing "people" (since Microsoft is hated around here anyway, such a vague accusation will increase your karma), but bribery it is a two-way street. By accusing Microsoft of bribing people, you are also accusing someone of accepting those bribes. Don't you think that those that voted YES have a right to be offended by your accusations that they took bribes?
If you would make specific charges, naming the individuals that accepted bribes (and provide some details, like the dollar amounts that changed hands), then you'd have more credibility, wouldn't be painting everyone with the "corruption" brush, and would give those specifically accused a chance to defend themselves. But as it is, you guys don't have the evidence or guts to make specific charges against specific people (like Jiri Kosek), so you make these vague unsupported charges.
DOJ v Microsoft was a CIVIL case. That's why a finding of liability only required the ruling of a single judge based on preponderance of evidence (i.e. what the judge feels is 50% + 1 of the evidence). This is a far cry from what findings of guilt require in CRIMINAL cases, which is a unanimous jury finding of guilt beyond a reasonable doubt. Also, if it were a criminal case, Microsoft wouldn't have been compelled to testify, but they were, as it was a civil case.
Finally, Antitrust is civil law, not criminal law (except in one extreme circumstance that is almost never been used).
You were nice enough in your post, but completely wrong.
Microsoft has never been accused of criminal violations (only civil ones, as had many big companies, such as Nintendo, Sony, IBM, etc (e.g. Nintendo was found guilty of price-fixing in Europe). Being accused of civil infractions and even being found in violation of civil law is not the same as being accused of criminal acts in criminal court. If that were the case, then many, many companies would be "criminal organizations". Losing a civil case is not the same thing as being convicted of a "crime", therefore losers of civil cases are not "criminals".
Oh please. Did you bother to look at the pictures? It's clear that this an invasion of privacy. Here's a clue. Read the articles again and look at the pictures again, but replace "Google" with "Microsoft", then see if you have the same opinion on the matter.
Damn, some people will defend Google no matter what they do. Just because someone claims that they're not evil, doesn't make it so. In fact, those that feel the need to constantly say "We're not evil" are *more* likely to be so. (It's like whenever you meet someone that says over and over, "I'm not a racist", nine times out of ten, they are a racist.)
I don't use Vista, but I don't make much of an issue of its being slower than XP. I mainly use Macs, and I know that OS X 10.0 was significantly slower than Mac OS 9/8/7 at the time it was released. I also remember that Win95 was slower than Win 3.1 and NT 3.1 was slower than Win 3.1 on similar hardware. I also know that today's Linux distros are slower than the ones from the 90's. One could run Linux acceptably on low-end 386 and even 286 hardware in the mid-90's. No way in hell could you do that with today's Linux distros. I also know that DOS is faster than any modern OS.
My point is, generally speaking, new OSes are slower than their predecessors. The question is whether the extra functionality is worth it. It definitely was in the case of OSX 10.0 vs Mac OS 9 and Win 95 vs Win3.1, and the other cases I mentioned above. Having not used Vista, I have no opinion on whether it's better enough than XP to overcome the slower speed.
Note: Yes, I know that OSX upgrades have generally gotten faster than their predecessors, particularly with OS X 10.2 and 10.3. But that's an exception to the general rule (and OS X 10.0 and 10.1 were so slow that it wasn't such a feat to make 10.2 and 10.3 faster).
I said at the time that OOXML's fast track process should be terminated after the Sweden incident (even if just for PR purposes, if nothing else). Then OOXML would go to the slow-track. Of course, Microsoft didn't want to use the slow-track process because by the time that process completed years later, IBM would've convinced governments to mandate exclusive use of ODF, and thereby make it illegal to use OOXML (which was the ultimate goal of anti-Microsoft forces). But I thought that if that's the price Microsoft had to pay for an employee's stupidity, then so be it.
That being said, the Sweden incident was much ado about nothing. Allow me to quote from an Arstechnica post by 'adminfoo': http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/718005041931?r=313007141931#313007141931
Do you know the full story of Sweden? How one employee sent an offer to two MS partners, which suggested that those partners should join the Swedish NB, and that MS would in some way pay them back for the joining fees - said mail was deemed inappropriate by MS and a retraction was sent within hours. And it was MS themselves who reported the incident to the Swedish NB - had they not done so, it's possible that no one would ever have heard this story. In the end, Sweden's NB abstained because of other issues.
(It is true that my given link is to a Microsoft employee telling the story - but you can find independent sources of the same thing if you look - and for all the scandal, no one has contradicted Matusow's more complete version of the tale.) BTW, IIRC, the fee for joining these committees is pretty small, so that doesn't provide much of a "bribery" incentive to begin with.
I don't get it. What is the basis of an antitrust suit? Are you guys now advocating that submitting a format to ISO (which doesn't force anyone to use the standard), is an antitrust violation? This is absurd. Hell, just a few years ago you same guys were saying it was abuse of monopoly, and therefore an antitrust violation, to NOT submit Microsoft's file formats to standards bodies. Make up your minds.
Re:Stop crying, people. Start being HONEST.
on
ISO Approves OOXML
·
· Score: 0, Troll
"Of course, the Czech Republic comments covered only a tiny fraction of what was wrong with the standard, so the actual improvement was, relatively speaking, fairly negligible - even when you take all the comments submitted by all the countries, there's still far more things left unfixed than there are things that have been fixed. (There just wasn't enough time to find everything.) It looks like several of the partially-resolved issues are still likely to break interoperability, too. To be honest, saying that "OK, we can approve it now" based on this seems a bit iffy..."
So are you saying that you agree with AlgorithMan (the guy to which I responded in my previous post) that all countries that switched from NO to YES took "bribes"? To be more specific, are you accusing the Czech Republic, and even more specifically, Jiri Kosek (the Czech Republic's expert, the one who wrote the evaluation I cited in my previous post), of taking a bribe? Remember, bribery is a two-way street. Many of you throw around accusations of Microsoft "bribing" people but in so doing you're also accusing the experts and government reps of accepting these bribes. I would like to know if you really want to go there (accusing real people (not just Microsoft or "governments", but real people), of taking bribes without any evidence to back up such an accusation).
"Did Microsoft happen to completely remove the Excel date bug specification from their so-called "standard"? If the answer is not "Yes", then the standard is still shoddy and should be discarded like the rubbish it is."
------------------- You refer to Excel's "feature" for being compatible with the leap-year bug introduced by Lotus 1-2-3 in the mid-1980's, right? This is tricky because there are in existence spreadsheet files that actually rely on the leap-year bug in order to work. These spreadsheet files may rely on the bug implicitly or explicitly (e.g. the spreadsheet author added code to the spreadsheet to workaround the bug), so fixing the bug would break these spreadsheets. (Anyone notice the irony that IBM, the owner of Lotus today, doesn't give a damn about helping users of Lotus 1-2-3 transition their files to ODF format and so is willing, and indeed proud, to provide no path to transition Lotus 1-2-3 files that rely on Lotus' leap-year bug to ODF? But I digress.)
This issue has been addressed in ISO OOXML. Brian Jones made numerous blog entries since the September vote on how this issue was resolved:
Folks have been discussing this one for about a year now; it's about the date format used in SpreadsheetML. In the Ecma responses and even in the BRM, we made a number of changes to make everyone happy. Here is where we are now with dates in SpreadsheetML:
* There is a new date datetype for cell values, and the only way to store into that datatype is with ISO 8601.
* For calculations primarily, there is often the need to convert from a date into a serial value or back. For this purpose you need to know the date base, or epoch, and in the ISO version of ODF there are essentially 3 date bases (only one of which is transitional)
* The leap year bug, and issues around dates before 1900 are now only allowed in transitional conformant files, but if the file is strict it cannot use these. [Snipped text that goes on to talk about how ODF allows multiple ways of storing dates, and implementors must similar conversion techniques as OOXML once the ODF 1.1 (the version that allows spreadsheet formulas) is released.] The upshot is that OOXML spreadsheets can only store dates in ISO 8601 format (unlike ODF, which stores dates in multiple formats), and while old "transitional conformant files" may rely on the leap-year bug, such files are not in "strict" compliance with OOXML.
So the leap-year bug is completely removed for new files, but can be used for transitional files. Which is essentially what you guys wanted, that old files may have to deal with legacy crap, but new files should be "clean". I'm sure this isn't enough to satisfy you, but it was enough for those that matter, and even Rob Weir hasn't made much effort to bash this resolution despite the leap-year bug being his main talking point for well over a year now.
This only further demonstrates how most of you are unaware of the improvements that have been made. The (ostensible) technical reasons for rejecting OOXML were addressed. All you have left are the political reasons, and such reasons should not impact ISO.
Re:Stop crying, people. Start being HONEST.
on
ISO Approves OOXML
·
· Score: 1
"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"?"
In fact I was really surprised how many "green boxes" are there at the end. I was expecting that ECMA will properly address only part of our comments. The vast majority of Czech comments was addressed by ECMA so it is time to say yes to OOXML. The countries that switched from NO to YES did so on the merits of the improvements that were made, not based on "bribes". That you and the others are actually accusing (both implicitly and explicitly) the Czech Republic and others that switched from NO to YES of taking bribes and whatnot with zero evidence is outrageous.
I don't care whether you complain that "truncateFoneHeightsLikeWP6" shouldn't be there in the first place. Go ahead and complain.
But the point is the poster to which I replied said, "Cue persistent formal requests to MS for specification details regarding "auto space like Word 95" et al. It's obviously the first step on the road to litigation/anti-trust cases.", completely unaware that "auto space like Word 95" has already been fully detailed in the ISO-approved spec. And it shows that most of you are speaking out of (sadly, willfull) ignorance on these matters.
"Cue persistent formal requests to MS for specification details regarding "auto space like Word 95" et al. It's obviously the first step on the road to litigation/anti-trust cases."
-------------- This shows your ignorance (and that of the general slashdot population). The "auto space like Word 95" issue has been addressed in the latest spec (the spec that's beeen approved). That "auto space like Word 95" behavior, and the others like it, are now marked as "deprecated" (i.e. should not use for new documents) AND are fully spec'ed.
Compatibility Settings - AutoSpaceLikeWord95
There has also been a lot of interest in the Compatibility Settings that include the famous "AutoSpaceLikeWord95" or "truncateFontHeightsLikeWP6". Ecma worked to provide in this batch the full information necessary to implement all compatibility settings without any dependency on any product. This documentation is provided for the completeness of the spec, but these features should not be used when creating new documents. I'll discuss the compatibility settings in more detail in my next post And here are further details.
See, this is the problem: So many of you that are railing against OOXML and against the ISO process are completely ignorant of the facts on the ground. The technical issues that you claimed to be concerned with have been addressed. So there's no technical reason to reject OOXML (there may be *political* reasons, but such reasons should have no bearing on ISO).
For example, the Czech Republic voted NO in September, but switched to YES. Why? Because nearly every one of their issues have been addressed now. http://xmlguru.cz/2008/01/ecma-response-to-czech-ooxml-comments Do you really expect the Czech Republic to continue to oppose OOXML when nearly all of its objections to the original spec have been fixed? Why would they do that? The problems were fixed, so they switched to YES, and this was the case with many countries (those without a political agenda).
It's like you guys are impervious to the fact that the OOXML spec has been quite improved (and that you're ranting about some old issue like "auto space like Word 95", an issue that has been resolved, *proves* it). Maybe, just maybe, if you took some time to learn the facts, learn how the spec has been changed since Sept, you'd not be so against OOXML (unless, as I suspect, your opposition is due to *political* reasons, under the mere guise of technical reasons).
"Yes, but most people actually wanted PDF to become an ISO standard. Adobe embraces the idea, and have since created a lot of competition against themselves, but they are willing to take this risk."
Is that why Adobe used legal threats in the EU to block Microsoft from adding built-in PDF support to Office 2007? Because they were willing to take a risk? Give me a break.
It's Microsoft that is willing to take a risk by making its XML format a standard AND releasing the spec to its binary formats as well, with no strings (unlike Adobe, which reserves the right to sue parties that implement PDF without its blessing, as they threatened to do to Microsoft).
I keep seeing this charge. Can you provide specifics? Yeah, I know about the Sweden incident last September, but MS reported that incident to the authorities themselves, and OOXML failed the September vote (to much rejoicing of slashdotters). But what about this new vote? Where is the evidence of "approval was purchased"? It seems to be a charge much bandied about around here without a shred of proof.
Why can't you accept the fact that OOXML failed the September vote due to technical problems, ECMA/MS addressed those problems, and thus removed any real reason to reject OOXML in the new vote. Or is it that the opposition in reality had nothing to due with technical problems, but was rather politically driven, and so even a 100% pristine "perfect" spec still wouldn't pass muster with the likes of you because of the politics?
Sounds like you're having difficulty accepting defeat and are engaged in spin. It's like the five stages of grief: 1. Denial 2. Anger 3. Bargaining 4. Depression 5. Acceptance
You're at stage 1 right now, trying to spin defeat into victory, and are already headed to stage 2 ("I'm really fucked off about...").
BTW, others have already implemented OOXML (the original ECMA version, though updates will be made for the new ISO version), but MSO will have no problem competing on features, UI, integration, enterprise solutions, office dev platform, etc.
Too bad OO.o sucks in general for the market that MS Works targets.
MS Works on Windows and iWork on Mac target those that don't need the power of MS Office and OO.o, and don't want to deal with the complications of those apps. MS Works and iWork offer task-based templates to get simple tasks done quickly. MSO offers that as well, but to a lesser extent, and OO.o is woefully lacking in that sort of thing.
More likely, since Office 2007 was made by Microsoft, you're predisposed hate it so you do. If Office 2007 were made by some OSS company, you'd be hailing it as a triumph of the OSS model, and you'd be ridiculing Microsoft for being stuck in the old UI paradigm of Office 2003 and its predcessors. And both you and I know it.
How would your example of "online stores with search fields" work? Google sends millions of different search queries to the server and index es each result?
The idea of sending automating form submissions seems very spammy.
Seems kind of weird (and wrong, frankly) to force another's server to handle automated bogus form submissions.
If this were an opt-in thing, then sure, those that want the content that resides behind forms to be indexed by google could opt for that. But google is making this an opt-out thing. If the web mananger has content that is only accessible via forms, then he probably doesn't intend for that content to be indexed. Google is saying, "Well use 'nofollow' links or edit the robots.txt file or whatever" (I'm not a web dev so I know next to nothing about such things), but it still forces the webdev to go back and "fix" his site to prevent form-hidden content from being googlized, which he didn't have to do before.
Anyway,
First, the "AutoSpaceLikeWord97" issue has been fixed. AutoSpaceLikeWord95 and the like have now been fully spec'ed and placed in the "transition conformance" section (i.e. those behaviors are deprecated, only for use in old documents).
See the AutoSpaceLikeWord95 section of this page.
And see supressTopSpacingWP, for example
Second, ISO OOXML spreadsheets have only one date format, the ISO 8601 date format. And the Lotus leap year bug behavior has been deprecated, only for use by old spreadsheets (that may rely on that behavior either implicitly or even explicitly). Moreover, ISO OOXML's date format is now simpler than ODF's.
Resolution of OOXML spreadsheet dates issue
Third, VML has also been deprecated, and new documents are only to use DrawingML. But you cite SVG; the thing about that is that what ODF calls "SVG" isn't actually SVG. ODF extends SVG's features, cuts lots of SVG's features, and changes the behavior of other SVG features, so that one cannot just use an SVG library to implement ODF's "SVG" functionality and call it done.
Embrace and extend - SVG in ODF revisited
Finally, of course, there are not yet any ISO OOXML implementations in the wild. But there aren't any full implementations of ODF in the wild either. Here's a list of ODF apps, scored on their ODF functionality, and no app achieves a perfect score, not even OO.o.
http://opendocumentfellowship.com/applications
In summary, many here talk of how horrible OOXML is by citing problems that have been resolved in the approved ISO revision. (I'm amazed that so many here are under the illusion that the problems cited with ECMA OOXML weren't addressed at all in the final ISO version. Under that misunerstanding, I can see where one might be tempted to believe that NO votes switching to YES votes could only be the result of bribery and corruption.)
Many here also are blissfully (willfully?) ignorant of ODf's own problems. I've almost NEVER seen a post, let alone an article, on ODF's problems, like its bastardization of SVG. For example, people here cite ODF's use of "SVG" as a virtue, unaware that ODF's "SVG" isn't really SVG.
The irony is that ISO now completely controls OOXML, while it does not control ODF (OASIS still does). Indeed, OASIS has made ODF 1.1 and 1.2, but hasn't bothered to submit either to ISO. (Which makes ODF 1.1 and 1.2 illegal for government use by governments that pass laws requiring ISO formats.)
The other irony that ODF was ratified by ISO, pretty much under the radar, with minimal scrutiny, while OOXML is probably the most scrutinized ISO standard ever. Yet the common belief around here is that OOXML was rushed through the ISO process. If any format was "rushed" through ISO, it was ODF. ODF 1.0 lacks major functionality (the most famous of which is support for spreadsheet formulas) and is essentially a 0.8ish format (rather than a 1.0 format). But this incomplete format was rushed through ISO, for the sole purpose of saying, "We are the first to get ISO's stamp, so our format is not just A standard, but THE standard, and ISO should reject all other standards in the future so that ODF rules forall time!" OOXML, on the other hand, slogged through a highly scrutinized process that resulted in an improvement over the ECMA OOXML 1.0, to a format more akin to a 1.5 format than a 1.0 format.
So, as things stand now, OOXML is more "open" (in that ISO controls it, unlike ODF) and more advanced (due to the high scrutiny that resulted in improvements (ISO's rush job on ODF didn't improve the format at all over what OASIS submitted).
You guys need to step back and see things for what they are.
Sadly, much of what you say applies to OO.o and ODF. OO.o's files aren't in full compliance with ISO ODF (and therefore OO.o's ODF can be differentiated from ISO ODF), and different apps exhibit different behaviors when reading ODF documents. Indeed, many ODF apps are "second-class" ODF apps.
Here's a rating of various application's ODF support, from one star to five stars (five stars means "perfect"):
http://opendocumentfellowship.com/applications
You'll note that NO app achieves 5 stars. There are a number of 4-star apps, but most are three stars and lower. (And I'd bet you a twinkie that nearly all (and possibly ALL) of the 4-star apps aren't independently developed from the spec, but are using rebranded versiond of OO.o's code. (It's known that many ODF apps are simply using OO.o code (the ODF spec is too vague in many places to create code simply based on the spec.)
(There's another web page on an ODF support site somewhere that lists details of problems when using particular apps to load ODF files created by other particlar apps (like using K-Office to load ODF files created by OO.o), but I can't find it at the moment.)
Sorry, but this has already been debunked:
Anti-OOXML guy posting your link and making your "private deal" charge on Rick Jelliffe's blog
Rick Jelliffe debunking the "secret deals" charge
Baseless accusations of bribery, et al, might be considered personal attacks by those on the receiving end.
The problem is that your accusations of bribery, et al, are so vague, that you're painting everyone that voted YES with the "corruption" brush. I wish you guys would man up and make a specific corruption charge against specific individuals.
For example, the Czech Republic's expert, Jiri Kosek, explained in great detail why the Czech Republic switched from NO to YES:
http://xmlguru.cz/2008/01/ecma-response-to-czech-ooxml-comments
Well, according to you guys, nobody in his right mind would switch from NO to YES without being bribed (or whatever), so let's get specific. Are you accusing Jiri Kosek of accepting a bribe, yes or no?
Sure, it's easy to accuse Microsoft of bribing "people" (since Microsoft is hated around here anyway, such a vague accusation will increase your karma), but bribery it is a two-way street. By accusing Microsoft of bribing people, you are also accusing someone of accepting those bribes. Don't you think that those that voted YES have a right to be offended by your accusations that they took bribes?
If you would make specific charges, naming the individuals that accepted bribes (and provide some details, like the dollar amounts that changed hands), then you'd have more credibility, wouldn't be painting everyone with the "corruption" brush, and would give those specifically accused a chance to defend themselves. But as it is, you guys don't have the evidence or guts to make specific charges against specific people (like Jiri Kosek), so you make these vague unsupported charges.
No, you're way off base.
DOJ v Microsoft was a CIVIL case. That's why a finding of liability only required the ruling of a single judge based on preponderance of evidence (i.e. what the judge feels is 50% + 1 of the evidence). This is a far cry from what findings of guilt require in CRIMINAL cases, which is a unanimous jury finding of guilt beyond a reasonable doubt. Also, if it were a criminal case, Microsoft wouldn't have been compelled to testify, but they were, as it was a civil case.
Finally, Antitrust is civil law, not criminal law (except in one extreme circumstance that is almost never been used).
You were nice enough in your post, but completely wrong.
How is that any different from XP-embedded?
Microsoft has never been accused of criminal violations (only civil ones, as had many big companies, such as Nintendo, Sony, IBM, etc (e.g. Nintendo was found guilty of price-fixing in Europe). Being accused of civil infractions and even being found in violation of civil law is not the same as being accused of criminal acts in criminal court. If that were the case, then many, many companies would be "criminal organizations". Losing a civil case is not the same thing as being convicted of a "crime", therefore losers of civil cases are not "criminals".
WTF does Acid3 have to do with open source? Opera was the first to pass Acid3, and it's closed source.
How about, if there's any question about it, then you assume the worst and not release the pictures?
:)
Or, one of Google's one thousand vaunted PhDs can create an AI program to analyze the pics. Peter Norvig (Google's AI master) can lead the effort.
Oh please.
Did you bother to look at the pictures? It's clear that this an invasion of privacy. Here's a clue. Read the articles again and look at the pictures again, but replace "Google" with "Microsoft", then see if you have the same opinion on the matter.
Damn, some people will defend Google no matter what they do. Just because someone claims that they're not evil, doesn't make it so. In fact, those that feel the need to constantly say "We're not evil" are *more* likely to be so. (It's like whenever you meet someone that says over and over, "I'm not a racist", nine times out of ten, they are a racist.)
I don't use Vista, but I don't make much of an issue of its being slower than XP. I mainly use Macs, and I know that OS X 10.0 was significantly slower than Mac OS 9/8/7 at the time it was released. I also remember that Win95 was slower than Win 3.1 and NT 3.1 was slower than Win 3.1 on similar hardware. I also know that today's Linux distros are slower than the ones from the 90's. One could run Linux acceptably on low-end 386 and even 286 hardware in the mid-90's. No way in hell could you do that with today's Linux distros. I also know that DOS is faster than any modern OS.
My point is, generally speaking, new OSes are slower than their predecessors. The question is whether the extra functionality is worth it. It definitely was in the case of OSX 10.0 vs Mac OS 9 and Win 95 vs Win3.1, and the other cases I mentioned above. Having not used Vista, I have no opinion on whether it's better enough than XP to overcome the slower speed.
Note: Yes, I know that OSX upgrades have generally gotten faster than their predecessors, particularly with OS X 10.2 and 10.3. But that's an exception to the general rule (and OS X 10.0 and 10.1 were so slow that it wasn't such a feat to make 10.2 and 10.3 faster).
That being said, the Sweden incident was much ado about nothing. Allow me to quote from an Arstechnica post by 'adminfoo':
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/718005041931?r=313007141931#313007141931 Do you know the full story of Sweden? How one employee sent an offer to two MS partners, which suggested that those partners should join the Swedish NB, and that MS would in some way pay them back for the joining fees - said mail was deemed inappropriate by MS and a retraction was sent within hours. And it was MS themselves who reported the incident to the Swedish NB - had they not done so, it's possible that no one would ever have heard this story. In the end, Sweden's NB abstained because of other issues.
(It is true that my given link is to a Microsoft employee telling the story - but you can find independent sources of the same thing if you look - and for all the scandal, no one has contradicted Matusow's more complete version of the tale.) BTW, IIRC, the fee for joining these committees is pretty small, so that doesn't provide much of a "bribery" incentive to begin with.
I don't get it. What is the basis of an antitrust suit? Are you guys now advocating that submitting a format to ISO (which doesn't force anyone to use the standard), is an antitrust violation? This is absurd. Hell, just a few years ago you same guys were saying it was abuse of monopoly, and therefore an antitrust violation, to NOT submit Microsoft's file formats to standards bodies. Make up your minds.
"Of course, the Czech Republic comments covered only a tiny fraction of what was wrong with the standard, so the actual improvement was, relatively speaking, fairly negligible - even when you take all the comments submitted by all the countries, there's still far more things left unfixed than there are things that have been fixed. (There just wasn't enough time to find everything.) It looks like several of the partially-resolved issues are still likely to break interoperability, too. To be honest, saying that "OK, we can approve it now" based on this seems a bit iffy..."
So are you saying that you agree with AlgorithMan (the guy to which I responded in my previous post) that all countries that switched from NO to YES took "bribes"? To be more specific, are you accusing the Czech Republic, and even more specifically, Jiri Kosek (the Czech Republic's expert, the one who wrote the evaluation I cited in my previous post), of taking a bribe? Remember, bribery is a two-way street. Many of you throw around accusations of Microsoft "bribing" people but in so doing you're also accusing the experts and government reps of accepting these bribes. I would like to know if you really want to go there (accusing real people (not just Microsoft or "governments", but real people), of taking bribes without any evidence to back up such an accusation).
-------------------
You refer to Excel's "feature" for being compatible with the leap-year bug introduced by Lotus 1-2-3 in the mid-1980's, right?
This is tricky because there are in existence spreadsheet files that actually rely on the leap-year bug in order to work. These spreadsheet files may rely on the bug implicitly or explicitly (e.g. the spreadsheet author added code to the spreadsheet to workaround the bug), so fixing the bug would break these spreadsheets. (Anyone notice the irony that IBM, the owner of Lotus today, doesn't give a damn about helping users of Lotus 1-2-3 transition their files to ODF format and so is willing, and indeed proud, to provide no path to transition Lotus 1-2-3 files that rely on Lotus' leap-year bug to ODF? But I digress.)
This issue has been addressed in ISO OOXML. Brian Jones made numerous blog entries since the September vote on how this issue was resolved:
2007-12-11: Allowing for ISO-8601 Dates
2007-12-21: Dates and the Leap Year Bug
2008-03-15: Discussion of dates and leap-year bug at the BRM
2008-03-25:
http://blogs.msdn.com/brian_jones/archive/2008/03/25/can-i-mention-that-it-s-also-in-odf.aspx Spreadsheet Dates
Folks have been discussing this one for about a year now; it's about the date format used in SpreadsheetML. In the Ecma responses and even in the BRM, we made a number of changes to make everyone happy. Here is where we are now with dates in SpreadsheetML:
* There is a new date datetype for cell values, and the only way to store into that datatype is with ISO 8601.
* For calculations primarily, there is often the need to convert from a date into a serial value or back. For this purpose you need to know the date base, or epoch, and in the ISO version of ODF there are essentially 3 date bases (only one of which is transitional)
* The leap year bug, and issues around dates before 1900 are now only allowed in transitional conformant files, but if the file is strict it cannot use these. [Snipped text that goes on to talk about how ODF allows multiple ways of storing dates, and implementors must similar conversion techniques as OOXML once the ODF 1.1 (the version that allows spreadsheet formulas) is released.] The upshot is that OOXML spreadsheets can only store dates in ISO 8601 format (unlike ODF, which stores dates in multiple formats), and while old "transitional conformant files" may rely on the leap-year bug, such files are not in "strict" compliance with OOXML.
So the leap-year bug is completely removed for new files, but can be used for transitional files. Which is essentially what you guys wanted, that old files may have to deal with legacy crap, but new files should be "clean". I'm sure this isn't enough to satisfy you, but it was enough for those that matter, and even Rob Weir hasn't made much effort to bash this resolution despite the leap-year bug being his main talking point for well over a year now.
This only further demonstrates how most of you are unaware of the improvements that have been made. The (ostensible) technical reasons for rejecting OOXML were addressed. All you have left are the political reasons, and such reasons should not impact ISO.
The Czech Republic, for one.
http://xmlguru.cz/2008/01/ecma-response-to-czech-ooxml-comments ECMA already provided proposed resolution for 75 comments (out of total 75 Czech comments). This means that 100.00% of Czech comments were handled by ECMA.
90.67% of comments were satisfactory resolved.
8.00% of comments were resolved only partially.
1.33% of comments were not satisfactory resolved.
...
In fact I was really surprised how many "green boxes" are there at the end. I was expecting that ECMA will properly address only part of our comments. The vast majority of Czech comments was addressed by ECMA so it is time to say yes to OOXML. The countries that switched from NO to YES did so on the merits of the improvements that were made, not based on "bribes". That you and the others are actually accusing (both implicitly and explicitly) the Czech Republic and others that switched from NO to YES of taking bribes and whatnot with zero evidence is outrageous.
I don't care whether you complain that "truncateFoneHeightsLikeWP6" shouldn't be there in the first place. Go ahead and complain.
But the point is the poster to which I replied said, "Cue persistent formal requests to MS for specification details regarding "auto space like Word 95" et al. It's obviously the first step on the road to litigation/anti-trust cases.", completely unaware that "auto space like Word 95" has already been fully detailed in the ISO-approved spec. And it shows that most of you are speaking out of (sadly, willfull) ignorance on these matters.
--------------
This shows your ignorance (and that of the general slashdot population). The "auto space like Word 95" issue has been addressed in the latest spec (the spec that's beeen approved). That "auto space like Word 95" behavior, and the others like it, are now marked as "deprecated" (i.e. should not use for new documents) AND are fully spec'ed. Compatibility Settings - AutoSpaceLikeWord95
There has also been a lot of interest in the Compatibility Settings that include the famous "AutoSpaceLikeWord95" or "truncateFontHeightsLikeWP6". Ecma worked to provide in this batch the full information necessary to implement all compatibility settings without any dependency on any product. This documentation is provided for the completeness of the spec, but these features should not be used when creating new documents. I'll discuss the compatibility settings in more detail in my next post And here are further details.
See, this is the problem: So many of you that are railing against OOXML and against the ISO process are completely ignorant of the facts on the ground. The technical issues that you claimed to be concerned with have been addressed. So there's no technical reason to reject OOXML (there may be *political* reasons, but such reasons should have no bearing on ISO).
For example, the Czech Republic voted NO in September, but switched to YES. Why? Because nearly every one of their issues have been addressed now.
http://xmlguru.cz/2008/01/ecma-response-to-czech-ooxml-comments
Do you really expect the Czech Republic to continue to oppose OOXML when nearly all of its objections to the original spec have been fixed? Why would they do that? The problems were fixed, so they switched to YES, and this was the case with many countries (those without a political agenda).
It's like you guys are impervious to the fact that the OOXML spec has been quite improved (and that you're ranting about some old issue like "auto space like Word 95", an issue that has been resolved, *proves* it). Maybe, just maybe, if you took some time to learn the facts, learn how the spec has been changed since Sept, you'd not be so against OOXML (unless, as I suspect, your opposition is due to *political* reasons, under the mere guise of technical reasons).
"Yes, but most people actually wanted PDF to become an ISO standard. Adobe embraces the idea, and have since created a lot of competition against themselves, but they are willing to take this risk."
Is that why Adobe used legal threats in the EU to block Microsoft from adding built-in PDF support to Office 2007? Because they were willing to take a risk? Give me a break.
It's Microsoft that is willing to take a risk by making its XML format a standard AND releasing the spec to its binary formats as well, with no strings (unlike Adobe, which reserves the right to sue parties that implement PDF without its blessing, as they threatened to do to Microsoft).
I keep seeing this charge. Can you provide specifics? Yeah, I know about the Sweden incident last September, but MS reported that incident to the authorities themselves, and OOXML failed the September vote (to much rejoicing of slashdotters). But what about this new vote? Where is the evidence of "approval was purchased"? It seems to be a charge much bandied about around here without a shred of proof.
Why can't you accept the fact that OOXML failed the September vote due to technical problems, ECMA/MS addressed those problems, and thus removed any real reason to reject OOXML in the new vote. Or is it that the opposition in reality had nothing to due with technical problems, but was rather politically driven, and so even a 100% pristine "perfect" spec still wouldn't pass muster with the likes of you because of the politics?
Sounds like you're having difficulty accepting defeat and are engaged in spin.
...").
It's like the five stages of grief:
1. Denial
2. Anger
3. Bargaining
4. Depression
5. Acceptance
You're at stage 1 right now, trying to spin defeat into victory, and are already headed to stage 2 ("I'm really fucked off about
BTW, others have already implemented OOXML (the original ECMA version, though updates will be made for the new ISO version), but MSO will have no problem competing on features, UI, integration, enterprise solutions, office dev platform, etc.