Why did Microsoft feel the need to invent, push, and strongarm OOXML when ODF already exists? A) Because ODF did not exist at the time Micrsoft started to use XML for their Office document formats.
B) Because ODF does not support the functionality that MS needs for it's Office suite
C) Because ODF is effective fully controlled by Sun and IBM which means that MS even though being the biggest Office software developer has no influence on features of ODF (which are purely driven by OOo development)
D) Because the EU asked Microsoft to standardise their Office document format at a standards organisation
To name a few
According to this Groklaw article there were 10,000+ comments.
http://www.groklaw.net/article.php?story=20070910110639612
Where does that leave the 6,500 missing comments? You do not know that Groklaw blatantly lies about 'facts' and moderates away people that they do not agree with what they write ?
The court order just tell them to make the protocols available at a non-discrimitory basis. It does not state the height of the compesation to charge.
The discussion in this article is about a report about the height of this compensation. A report does not make for a court order.
However the report could lead to the EU demanding that the fees Micrsoft demands for these protocols a slashed and then again a fine if Microsoft fails to comply.
The size is not a problem.
There is already a full implementation of the spec which is not the case for the much smaller ODF specification. Size does not nescesarily represent more complexity.
Also in fasttracking you do not need to judge every element of the spec as you fastrack an existing standard but you need to look at thing like if this existing technology adds something additional to ISO standards and if the market can use this as a standard for office documents and if the spec contradicts the use of other ISO specs.
Most complaints made by the national bodies were provoked by a mailing campaign by Groklaw to the national bodies (seeing identical issues raised). However the Groklaw issues are either not really issues or mostly non-relevant in a fastracking procedure which has no requirement to validate each element in the spec.
It is good to remember that a for a complex standard like this it is unlikely that the first version is 100% correct. There is time to improve the standard in future version and ISO can pro-activly ask Ecma to commit to cwertain changes in such future version during this proces.
The national bodies get to vote at the end of the 5 motnh nballot period that is now starting.
The early contradictions review is not ment to block the fasttracking process by ISO. It makes it possible for the body that entered the proposal to see whether the proposal is can continue or that amendments need to be made or if the proposal better be withdrawn.
As Ecma has answered the issues raised by the national bodies and seems not intent on withdrawing the proposal or amending it at this time the normal procedure would dictate the fasttrack proces continues. It could still be that during the 5 month ballot period Ecma amends the proposal if the national bodies require more than what was in Ecma's first answer. also possible is that Ecma makes a commitment to alter certain features in a future version (like OASIS is doing with ODF). For instance ecma could commit to removing bitmask from the spec in v1.1 and add additional support for iso dates in spreadhseet cells.
You are the person not getting the point. If MS were to create a new version of OOXML and not license it in the same way it cannot become a standard. The standard will then remain the old version and MS Office would not comply to a standard anymore. That would be a stupid move.
On the other hand the covenant not to sue made by Sun in regards to ODF format specifically states that if Sun is not involved in the developement of a new version than the covenant does not apply to that v ersion. So sun has the same hold on development of the ODF format as MS does on the OOXML format. However development for MS is crucial for it's products and whilst Sun could just hold up development of ODF indefinitly if MS were to use it because for Sun the format is no primary business.
It has taken OpenOffice almost two years since standardization and still they cannot fully support ODF yet and they actually started with a big headstart. You comment suggest that one can just built in ODF support on any an accepetable level for MS Office not realistic. MS Office has even more features and also would have to adapt and or extend on ODF to put al those features in ODF (or they would be accussed of adding a handicapped implementation of ODF).
Adding a complex fileformat and fully supporting it is also a very complex and lengty process. By using the plugin support the ODF support can be continuously developed and if in the future the need is there to add ODF support directly in MS office they can reuse that code as I think they released in on an OSS license that does not require implementations to share it's code.
Slashdot Mirror
In fact it is only 1000 distinct comments if you read the blog of the Alex Brown who will be convening the ballot resolution meeting http://adjb.net/index.php?entry=entry071024-180256.
The issue is not about the content of information (anymore) but about the price of that information.
The court order just tell them to make the protocols available at a non-discrimitory basis. It does not state the height of the compesation to charge. The discussion in this article is about a report about the height of this compensation. A report does not make for a court order. However the report could lead to the EU demanding that the fees Micrsoft demands for these protocols a slashed and then again a fine if Microsoft fails to comply.
What standards ? In this area of connecting server and client software Microsoft is setting a lot of the standards.
The size is not a problem. There is already a full implementation of the spec which is not the case for the much smaller ODF specification. Size does not nescesarily represent more complexity. Also in fasttracking you do not need to judge every element of the spec as you fastrack an existing standard but you need to look at thing like if this existing technology adds something additional to ISO standards and if the market can use this as a standard for office documents and if the spec contradicts the use of other ISO specs. Most complaints made by the national bodies were provoked by a mailing campaign by Groklaw to the national bodies (seeing identical issues raised). However the Groklaw issues are either not really issues or mostly non-relevant in a fastracking procedure which has no requirement to validate each element in the spec. It is good to remember that a for a complex standard like this it is unlikely that the first version is 100% correct. There is time to improve the standard in future version and ISO can pro-activly ask Ecma to commit to cwertain changes in such future version during this proces.
The national bodies get to vote at the end of the 5 motnh nballot period that is now starting. The early contradictions review is not ment to block the fasttracking process by ISO. It makes it possible for the body that entered the proposal to see whether the proposal is can continue or that amendments need to be made or if the proposal better be withdrawn. As Ecma has answered the issues raised by the national bodies and seems not intent on withdrawing the proposal or amending it at this time the normal procedure would dictate the fasttrack proces continues. It could still be that during the 5 month ballot period Ecma amends the proposal if the national bodies require more than what was in Ecma's first answer. also possible is that Ecma makes a commitment to alter certain features in a future version (like OASIS is doing with ODF). For instance ecma could commit to removing bitmask from the spec in v1.1 and add additional support for iso dates in spreadhseet cells.
You are the person not getting the point. If MS were to create a new version of OOXML and not license it in the same way it cannot become a standard. The standard will then remain the old version and MS Office would not comply to a standard anymore. That would be a stupid move. On the other hand the covenant not to sue made by Sun in regards to ODF format specifically states that if Sun is not involved in the developement of a new version than the covenant does not apply to that v ersion. So sun has the same hold on development of the ODF format as MS does on the OOXML format. However development for MS is crucial for it's products and whilst Sun could just hold up development of ODF indefinitly if MS were to use it because for Sun the format is no primary business.
It has taken OpenOffice almost two years since standardization and still they cannot fully support ODF yet and they actually started with a big headstart. You comment suggest that one can just built in ODF support on any an accepetable level for MS Office not realistic. MS Office has even more features and also would have to adapt and or extend on ODF to put al those features in ODF (or they would be accussed of adding a handicapped implementation of ODF). Adding a complex fileformat and fully supporting it is also a very complex and lengty process. By using the plugin support the ODF support can be continuously developed and if in the future the need is there to add ODF support directly in MS office they can reuse that code as I think they released in on an OSS license that does not require implementations to share it's code.