Gary Edwards's Bookmarks tagged ecma376 →  View Popular

Whoa, another must read analysis of OOXML. This one is provided by the University of Toronto, with a focus on "accessibility" issues. Not surprisingly, OOXML fails on nearly all counts.



The authors recommend that we go back to work on improving ODF and the accessibility of ODF ready applications.

Looks like the road to open standards now detours through Redmond, Washington.  Can we still call the destiny "open standards" if proposals have to be filtered through the Microsoft business plan for world domination?  This is not a good day for America.

The fast track problem may be more serious than most think.  NB's such as the USA Department of Commerce NiST authorized ANSI/INCiTS group, who have opted to keep Ecma 376 on the fast track, may have compromised their legal standing with sponsoring governments. 

As it sits, an ISO/IEC ratification of Ecam 376 would violate International Trade Agreements.  Without a diligent and careful review / amendment of Ecma 376, ISO/IEC is going to find itself in a difficult to explain position.

A wide array of Microsoft sponsored and business affiliated technical punditry has weighed in arguing on behalf of fast tracking Ecma 376, even though the contradictions with existing ISO/IEC product 26300 are <b><a href="http://www.grokdoc.net/index.php/EOOXML_objections">legion</a></b>.

Marbux is one legal expert quite familiar with International Law and Trade Agreements, and their impact on International Standards.  He has researched the Ecma 376 ISO/IEC contradiictions and fast track process with such thoroughness that his commentary, <b><a href="http://www.opendocumentfellowship.org/node/303">What is a contradiction at ISO?</a></b> has become a must read. 

~ge~

Great article by Evan Leibovitch.  His approach to the issue of MS Ecma 376 is refreshingly different in that he sees the success of OpenDocument as a user challenge to years of softwware vendor control: 

"For the first time in decades, major IT users are challenging the traditional proprietary formats used by software programs...."

Evan goes on to sight Rob Weirs blog as evidence that MS Ecma 376 continues the long traditon of vendor control through the binidng of file formats to proprietary applications. 

Microsoft Wikipedia Shill Rick Jelliffe weighs in on the "contradiction" definition issue.  Rick is well known XML expert, and prior to his contracting out as a hired shill for Microsoft, was much respected.  Patrick Durusau, ODF editor and co chairman of the ISO/IEC JTSC1 committee that reviewed ODF and will be responsible for MS Ecma 376, requested the clarification.

Rick J provides a nice framework for approachign the "contradiction definition" issue, but fails to provide an expert opinion on MS Ecma 376. 

Anyone familiar with Rick's comments in the past will come away from this article much surprised.  He went all wobbly when it came time to make the call on MS Ecma 376.  This kind of wishy washy opinion is hardly what we've come to expect. 

I guess the shill contract incuded much more than pasting up Wikipedia to make Microsoft look like an honest broker of information technologies. 

~ge~

Microsoft Wikipedia Shill Rick Jelliffe weighs in on the "contradiction" definition issue.  Rick is well known XML expert, and prior to his contracting out as a hired shill for Microsoft, was much respected.  Patrick Durusau, ODF editor and co chairman of the ISO/IEC JTSC1 committee that reviewed ODF and will be responsible for MS Ecma 376, requested the clarification.

Rick J provides a nice framework for approachign the "contradiction definition" issue, but fails to provide an expert opinion on MS Ecma 376. 

Anyone familiar with Rick's comments in the past will come away from this article much surprised.  He went all wobbly when it came time to make the call on MS Ecma 376.  This kind of wishy washy opinion is hardly what we've come to expect. 

I guess the shill contract incuded much more than pasting up Wikipedia to make Microsoft look like an honest broker of information technologies. 

~ge~

Well, this is interesting.

What part of "Executive Board"
makes you think they read 6,000 page XML specifications? <ge>



I think, in the best bureaucratic tradition,
they argued definitions until they convinced themselves that they didn't
need to do anything.  They decided that one standard contradicts another
standard only if the proposed standard causes the existing standard not
to work.  This is from analogy with the Chinese WAPI WiFi networking
standard last year that was defeated because the protocol caused radio
interference with existing 801.11 networks.  So they said that OOXML
did not contradict ODF because both files could exist on the same disk
without interfering with each other.   You will note that thiss argument
can be used for every XML format, every programming language, every operating
system, in fact every software standard, since software is ultimately data,
and data can be segregated on disks.  So they essentially chose a
definition so narrow that it nullified the concept of "contradiction"
for most of what JTC1 has authority over.

<!--
D(["mb","<div><br><span style\u003d\"color:rgb(0, 0, 153)\"><ge>  Wait a second.   You cannot have a OOXML document and a ODF document sitting on the same disk without having them interfer with each other.  We just proved that with our tests of both ACME 374 and ODF Da Vinci plugin on the latest release of MSOffice Word 2007.\n</span><br style\u003d\"color:rgb(0, 0, 153)\"><br style\u003d\"color:rgb(0, 0, 153)\"><span style\u003d\"color:rgb(0, 0, 153)\">OOXML clearly does interfere with the loading of an ODF file into MSWord 2007.  In prior versions of MSWord (98, 2000, XP, 2003), the Da Vinci plugin successfully loadedd ODF files into MSWord.  With the release of MSWord 2007, which is the first OOXML enabled release, the Da Vinci plugin loading of an ODF file is seriously interfered with, to the point of blocking the use of ODF documents.  \n</span><br style\u003d\"color:rgb(0, 0, 153)\"><br style\u003d\"color:rgb(0, 0, 153)\"><span style\u003d\"color:rgb(0, 0, 153)\">ODF and OOXML are both .zip containers.  When we try to load the ODF file, the system defaults to the OOXML conversion filters, thinking that the the ODF file is a OOXML document!  The ODF conversion filters for MSWord are pushed aside by OOXML filters - a confusion directly traceable to the fact that ODF and OOXML are both .zip containers!\n<br><br>This has to be a potentially confusing and infinitely frustrating problem for users.  If ISO/IEC approves Ecma 376, there will be millions of disk out there with both ODF and OOXML files.  Prior to the appearance of OOXML as the default file format in MSWord, we were able to load and save ODF documents.  Noww we can't?  \n<br></span></div>",1]
);

//--><!--
D(["mb","<span class\u003dq><br><blockquote class\u003d\"gmail_quote\" style\u003d\"border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex\"><font face\u003d\"sans-serif\" size\u003d\"2\">This was very selective cherry picking\nof precedents, since eveen last year there were contradictions raised against\nMicrosoft/Ecma's C++/CLI standard in JTC1 based purely on user confusion,\ndifferences with the ISO C++ specification, confusion over the name, etc.\n No one had to demonstrate some sort of fundamental mechanical conflict\nbetween the two standards.</font></blockquote></span>",1]
);
D(["mb","<div><br><span style\u003d\"color:rgb(0, 0, 153)\"><ge> I think this qualifies as a "mechanical conflict".  One guaranteed to be greatly compounded by user confuser.\n<br><br>We need to run more tests of Da Vinci installs into legacy MSOffice systems running the OOXML Compatibility Pack, with OOXML set as the file format default.  Still, MSOffice 2007 seems to prove the conflict between ODF and OOXML files residing on the same disk, with OOXML seriously interfering with ODF use.\n<br></span></div>",1]
);