the argument is incorrect. "Most" of the arguments being made against OOXML are based on these two facts: (1) There are hundreds of technical problems with OOXML (literally hundreds... read the articles) that were found by those who studied it, and which Microsoft has refused to address To my knowledge, this is no longer true. What are the "technical problems with OOXML that Microsoft has refused to address"?
This is not something I made up. All you have to do is read the articles linked to from here, and perhaps Ars Technica. Other places too, but that should be enough to convince anyone. Actually, I have first-hand knowledge both of the many technical problems with OOXML that have been reported by the various national bodies and of the willingness of Microsoft at the Ballot Resolution Meeting for these problems to be addressed.
autoSpaceLikeWord95 and useWord97LineBreakRules
on
India Votes Against OOXML
·
· Score: 5, Informative
autoSpaceLikeWord95 This is defined on pages 136-137 of the "dipositions of comments" document SC34N0980, and the decision has been made at the BRM to incorporate this definition into the draft standard.
useWord97LineBreakRules. This is defined on pages 147-148 of the "dipositions of comments" document SC34N0980, and the decision has been made at the BRM to incorporate this definition into the draft standard.
How is it then, that no matter how positive the articles is to open standards, the situation always gets spun as MS vs MS competitors? From the perspective of document format users, OOXML is better than what MS customers had before.
From the perspective of MS competitors, OOXML is an attempt to kill the document format that they have been investing in (ODF).
OOXML isn't properly documented so it cannot be called a standard.
While I'm as much opposed as you are to "approval as an ISO/iEC standard" of the mess which OOXML currently is, to my knowledge the above criticism is not valid anymore. What specifically is in your opinion "not properly documented"?
Completely agreed. Voting for what is genuinely in the public interest doesn't imply honesty. In fact, most of the arguments which are being made against MS-OOXML are based on misinformed, false premises or are otherwise dishonest. (The same can be said about most of the arguments in favor of MS-OOXML).
OOXML can't kill ODF, because ODF is open, and OOXML isnt. People who want to guarantee access to their documents in perpetuity (eg legitimate governments) cannot use OOXML because it cannot meet their needs.
Microsoft is working hard on making OOXML as open as it needs to be in order to meet the requirements of the relevant decision-makers. Of course, whether that is open enough to allow genuine free software implementations is not a question that Microsoft really cares about, so we have to educate the decision-makers about what are the important criteria.
But if you think that ODF can survive in competition against OOXML if both are ISO standards, you're kidding yourself.
In my opinion, any national body which at the current state votes for OOXML to become an ISO standard is definitely dishonest.
Either they are dishonest because they don't understand what they're doing while claiming to understand, or they're dishonest because they're knowingly voting against their country's best interest.
Nota bene, the representatives of Microsoft Corporation and partner companies are not necessarily dishonest in their lobbying for "APPROVE" votes, since what they ask for is genuinely in their interest. But the national bodies are supposed to represent the correspondiong national interest!
There is a lot of rhetorics around "one standard" vs "multiple
standards". A major reason for this is the ISO/IEC rules which
way that there should not be "contradicting" standards, while
in reality this rule is not generally followed.
In fact facilitating technical progress requires that the
"no contradicting standards" rule cannot be strictly enforced.
In this situation however there is a serious problem. Because
of Microsoft's dominant market position, if OOXML gets ISO/IEC
approval, that will probably kill ODF. The problem with this
is that this kills investments in ODF. If Microsoft is allowed
to get away with this, the net result will be a chilling effect
on all investments in non-Microsoft standards.
Sounds interesting - I wasn't aware that SVG defines enough functionality that it could serve as a genuinely open Flash/Silverlight competitor. Where can I find detailed information about this?
It matters what kinds of webpages you test, and precisely what workflow you simulate.
Regardless of what benchmarking tool you use when working on improving the performance of some program, it is close to unavoidable that by doing so, you optimize for scoring well under the particular kind of tests that you're running. This is a major source of bias.
Flash and Silverlight are fully documented, and there exists free implemenetations: Gnash and Moonlight, respectively.
I tried Gnash recently, and the video that I tried to view simply didn't play.
In addition, Adobe does not allow the documentation for Flash to be used for making or improving a free software viewer.
Regarding Silverlight: yes, the docs appear to be not restricted in such a way, however that is not good enough. Who knows whether the documentation is complete? In addition, without formal standardization, nothing stops Microsoft from extending the format whenever they like and forcing free software implementations to play catch-up-if-you-can.
Furthermore, there is always the potential issue with patents, which means that it is never clear that something which looks like free software really is free software as long as whoever has developed the underlying design hasn't made a a clear patent non-assertion promise. This is particularly problematic with regard to Novell and the Mono project in general, and especially so with regard to Moonlight: It appears that Novell is depending on this non-free patent license from Microsoft in a way from which I can only conclude that Moonlight is not free software.
Does that mean that it MAY not be? Because the story itself and the accompanying graph seem to indicate that it IS, not that it MAY be. Just, like, clarify, you know?
This is just the result of one test with one benchmarking tool; on top of that, it was a test with the vendor's own tool. The "MAY" in the article reflects the uncertainty regarding whether this tool and the particular test conducted with it appropriately reflects real-life usage scenarios.
Ok, so the Mozilla folks have succeeded in improving their browser's
resource efficiency enough that it beats the competition
on their own benchmark.
The more interesting question is of course whether the firebox beta
also wins when other benchmarking tools including those produced by
competiting browser developers are used.
It was the EU, in 2004, along with some other governments, that asked Microsoft to submit their formats for standardization. So now they don't like this?
Let's not forget the reason for wanting open standards for document formats. No-one (with the possible exception of Microsoft itself) can possibly wants to be locked in by means of document formats to be forced to use Microsoft products forever.
The solution to this problem is standardization. The approval process for international standards is supposed to guarantee that no document format with vendor lock-in properties can be approved as an international standard. That's why it was a totally reasonable step from the EU's perspective to demand standardization of Microsoft's formats. That would have solved the lock-in problem without forcing the EU to undertake the expense of e.g. migrating to using ODF.
However it seems that Microsoft's strategy is make OOXML "open" in name but not in reality (that would mean making it effectively possible for competitors to compete with Microsoft regarding "who has the best implementation of OOXML" - however Microsoft is careful to prevent effective competition of that kind) and push it through the ISO approval process nevertheless by means of tactics involving committee-stacking.
Of course the EU must say "NO!" to that if they don't want to lose their credibility completely!
A lot of this is a nuisance for them and well within what they probably consider the cost of doing business.
This isn't about trying to hurt Microsoft. This is about influencing the verious national standardization bodies to take effective action against committee stacking.
Without this kind of high-level antitrust complaint, the tempation for national standardization bodies (NBs = "national bodies") to sweep all complaints regarding committee-stacking under the rug is just too great. After all, they're getting some money from each company that delegates an "expert" into the committee, regardless of whether that person is a genuine expert of the subject matter under consideration or someone who doesn't know anything of relevance beyond "my company supports OOXML". Add to this that the NBs are really dependent on the "convenors" (chairs) of the decision-making committees. These are not paid by the NB but rather by some company which has delegated this person into the committee. If no-one is willing to do this convenor work, standardization work will stop in the NB for that topic area, and the NB will no longer be able to collect membership fees from companies interested in standardization work in that topic area. For that reason, NBs are very reluctant to do anything that might cause a "convenor" to quit. A demand to take effective action against committee-stacking could make the convenor's role much more difficult, while driving away the only person willing to be "convenor" is an outcome that the NB absolutely has to avoid. Solutions to the problem are possible, for example I have heard that DIN (the German NB) has a reasonable set of rules, but many NBs have a serious problem which can only be addressed by means of a painful reform...
Slashdot Mirror
From the perspective of MS competitors, OOXML is an attempt to kill the document format that they have been investing in (ODF).
While I'm as much opposed as you are to "approval as an ISO/iEC standard" of the mess which OOXML currently is, to my knowledge the above criticism is not valid anymore. What specifically is in your opinion "not properly documented"?
Completely agreed. Voting for what is genuinely in the public interest doesn't imply honesty. In fact, most of the arguments which are being made against MS-OOXML are based on misinformed, false premises or are otherwise dishonest. (The same can be said about most of the arguments in favor of MS-OOXML).
OOXML can't kill ODF, because ODF is open, and OOXML isnt. People who want to guarantee access to their documents in perpetuity (eg legitimate governments) cannot use OOXML because it cannot meet their needs.
Microsoft is working hard on making OOXML as open as it needs to be in order to meet the requirements of the relevant decision-makers. Of course, whether that is open enough to allow genuine free software implementations is not a question that Microsoft really cares about, so we have to educate the decision-makers about what are the important criteria.
But if you think that ODF can survive in competition against OOXML if both are ISO standards, you're kidding yourself.
Either they are dishonest because they don't understand what they're doing while claiming to understand, or they're dishonest because they're knowingly voting against their country's best interest.
Nota bene, the representatives of Microsoft Corporation and partner companies are not necessarily dishonest in their lobbying for "APPROVE" votes, since what they ask for is genuinely in their interest. But the national bodies are supposed to represent the correspondiong national interest!
In fact facilitating technical progress requires that the "no contradicting standards" rule cannot be strictly enforced.
In this situation however there is a serious problem. Because of Microsoft's dominant market position, if OOXML gets ISO/IEC approval, that will probably kill ODF. The problem with this is that this kills investments in ODF. If Microsoft is allowed to get away with this, the net result will be a chilling effect on all investments in non-Microsoft standards.
Sounds interesting - I wasn't aware that SVG defines enough functionality that it could serve as a genuinely open Flash/Silverlight competitor. Where can I find detailed information about this?
Regardless of what benchmarking tool you use when working on improving the performance of some program, it is close to unavoidable that by doing so, you optimize for scoring well under the particular kind of tests that you're running. This is a major source of bias.
I tried Gnash recently, and the video that I tried to view simply didn't play.
In addition, Adobe does not allow the documentation for Flash to be used for making or improving a free software viewer.
Regarding Silverlight: yes, the docs appear to be not restricted in such a way, however that is not good enough. Who knows whether the documentation is complete? In addition, without formal standardization, nothing stops Microsoft from extending the format whenever they like and forcing free software implementations to play catch-up-if-you-can.
Furthermore, there is always the potential issue with patents, which means that it is never clear that something which looks like free software really is free software as long as whoever has developed the underlying design hasn't made a a clear patent non-assertion promise. This is particularly problematic with regard to Novell and the Mono project in general, and especially so with regard to Moonlight: It appears that Novell is depending on this non-free patent license from Microsoft in a way from which I can only conclude that Moonlight is not free software.
What will it take to replace both Flash and Silverlight by a genuinely open standard (that has a Free Software implementation)?
This is just the result of one test with one benchmarking tool; on top of that, it was a test with the vendor's own tool. The "MAY" in the article reflects the uncertainty regarding whether this tool and the particular test conducted with it appropriately reflects real-life usage scenarios.
The more interesting question is of course whether the firebox beta also wins when other benchmarking tools including those produced by competiting browser developers are used.
Let's not forget the reason for wanting open standards for document formats. No-one (with the possible exception of Microsoft itself) can possibly wants to be locked in by means of document formats to be forced to use Microsoft products forever.
The solution to this problem is standardization. The approval process for international standards is supposed to guarantee that no document format with vendor lock-in properties can be approved as an international standard. That's why it was a totally reasonable step from the EU's perspective to demand standardization of Microsoft's formats. That would have solved the lock-in problem without forcing the EU to undertake the expense of e.g. migrating to using ODF.
However it seems that Microsoft's strategy is make OOXML "open" in name but not in reality (that would mean making it effectively possible for competitors to compete with Microsoft regarding "who has the best implementation of OOXML" - however Microsoft is careful to prevent effective competition of that kind) and push it through the ISO approval process nevertheless by means of tactics involving committee-stacking.
Of course the EU must say "NO!" to that if they don't want to lose their credibility completely!
This isn't about trying to hurt Microsoft. This is about influencing the verious national standardization bodies to take effective action against committee stacking.
Without this kind of high-level antitrust complaint, the tempation for national standardization bodies (NBs = "national bodies") to sweep all complaints regarding committee-stacking under the rug is just too great. After all, they're getting some money from each company that delegates an "expert" into the committee, regardless of whether that person is a genuine expert of the subject matter under consideration or someone who doesn't know anything of relevance beyond "my company supports OOXML". Add to this that the NBs are really dependent on the "convenors" (chairs) of the decision-making committees. These are not paid by the NB but rather by some company which has delegated this person into the committee. If no-one is willing to do this convenor work, standardization work will stop in the NB for that topic area, and the NB will no longer be able to collect membership fees from companies interested in standardization work in that topic area. For that reason, NBs are very reluctant to do anything that might cause a "convenor" to quit. A demand to take effective action against committee-stacking could make the convenor's role much more difficult, while driving away the only person willing to be "convenor" is an outcome that the NB absolutely has to avoid. Solutions to the problem are possible, for example I have heard that DIN (the German NB) has a reasonable set of rules, but many NBs have a serious problem which can only be addressed by means of a painful reform...