The following six questions relate to the application of the ECMA/MS-OOXML 
format to be accepted as an IEC/ISO standard. Unless a national standardisation 
body has conclusive answers to all of them, it should vote no in IEC/ISO and 
request that Microsoft incorporate its work on MS-OOXML into ISO/IEC 26300:2006 
(Open Document Format).

This is a summary document. More detailed information is available online.

    * http://www.grokdoc.net/index.php/EOOXML_objections
    * http://www.xmlopen.org/ooxml-wiki/index.php/DIS_29500_Comments
    * http://www.noooxml.org/arguments

   1.
      Application independence?

      No standard should ever depend on a certain operating system, environment 
or application. Application and implementation independence is one of the most 
important properties of all standards.

          Is the MS-OOXML specification free from any references to particular 
products of any vendor and their specific behaviour? 

   2.
      Supporting pre-existing Open Standards?

      Whenever applicable and possible, standards should build upon previous 
standardisation efforts and not depend on proprietary, vendor-specific 
technologies.

      MS-OOXML neglects various standards, such as MathML and SVG, which are 
recommendations by the W3C, and uses its own vendor-specific formats instead. 
This puts a substantial burden on all vendors to follow Microsoft in its 
proprietary infrastructure built over the past 20 years in order to fully 
implement MS-OOXML. It seems questionable how any third party could ever 
implement them equally well.

          What is the benefit of accepting usage of such vendor-specific 
formats at the expense of standardisation in these areas? Where will other 
vendors get competitive, compatible and complete implementations for all 
platforms to avoid prohibitively large investments? 

   3.
      Backward compatibility for all vendors?

      One of the alledged main advantages of MS-OOXML is its ability to allow 
for backward compatibility, as also referenced in the ECMA International press 
release.

      For any standard it is essential that it is implementable by any third 
party without necessity of cooperation by another company, additional 
restricted information or legal agreements or indemnifications. It is also 
essential to not require the cooperation of any competitor to achieve full and 
comparable interoperability.

          On the grounds of the existing MS-OOXML specification, can any third 
party regardless of business model, without access to additional information 
and without the cooperation of Microsoft implement full backward compatibility 
and conversion of such legacy documents into MS-OOXML comparable to what 
Microsoft can offer? 

   4.
      Proprietary extensions?

      Proprietary, application-specific extensions are a known technique 
employed in particular by Microsoft to abuse and leverage its desktop monopoly 
into neighboring markets. It is a technique at the heart of the abusive 
behaviour that was at the core of the decision against Microsoft by the 
European Commission in 2004 and Microsoft is until today continuing its refusal 
to release the necessary interoperability information.

      For this reason, it is common understanding that Open Standards should 
not allow such proprietary extensions, and that such market-distorting 
techniques should not be possible on the grounds of an Open Standard.

          Does MS-OOXML allow proprietary extensions? Is Microsoft's 
implementation of MS-OOXML faithful, i.e. without undocumented extensions? Are 
there safeguards against such abusive behaviour? 

   5.
      Dual standards?

      The goal of all standardisation is always to come to one single standard, 
as multiple standards always provide an impediment to competition. Seeming 
competition on the standard is truly a strategic measure to gain control over 
certain segments of a market, as various examples in the past have demonstrated.

      There is an existing Open Standard for office documents, namely the Open 
Document Format (ODF) (ISO/IEC 26300:2006). Both MS-OOXML and ODF are built 
upon XML technology, so employ the same base technology and thus ultimately 
have the same theoretical capabilities. Microsoft itself is a member of OASIS, 
the organisation in which the ODF standard was developed and is being 
maintained. It was aware of the process and invited to participate.

          Why did and does Microsoft refuse to participate in the existing 
standardisation effort? Why does it not submit its technological proposals to 
OASIS for inclusion into ODF? 

   6.
      Legally safe?

      Granting all competitors freedom from legal prosecution for 
implementation of a standard is essential. Such a grant needs to be clear, 
reliable and wide enough to cover all activities necessary to achieve full 
interoperability and allow a level playing field for true competition on the 
merits.

      MS-OOXML is accompanied by an unusually complex and narrow "covenant not 
to sue" instead of the typical patent grant. Because of its complexity, it does 
not seem clear how much protection from prosecution for compatibility it will 
truly provide.

      Cursory legal study implies that the covenant does not cover all optional 
features and proprietary formats mandatory for complete implementation of 
MS-OOXML. So freedom of implementation by all competitors is not guaranteed for 
the entire width of the proposed MS-OOXML format, and questionable even for the 
core components.

          Does your national standardisation body have its own, independent 
legal analysis about the exact nature of the grant to certify whether it truly 
covers the full spectrum of all possible MS-OOXML implementations? 

All these questions should have answers that should be provided by the national 
standardisation bodies through independent counsel and experts, and in 
particular not by Microsoft or its business partners, which have a direct 
conflict of interest on this issue.

If there is no good answer to any one of them, a national body should vote no 
in ISO/IEC. 


      

--~--~---------~--~----~------------~-------~--~----~
FOSS Nepal mailing list: [email protected]
http://groups.google.com/group/foss-nepal
To unsubscribe, e-mail: [email protected]

Community website: http://www.fossnepal.org/
-~----------~----~----~----~------~----~------~--~---

Reply via email to