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. </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. </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! <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? <br></span></div>",1] );
//-->
<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.
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 loaded 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.
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!
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. Now we can't?
<!-- 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 of precedents, since eveen last year there were contradictions raised against Microsoft/Ecma's C++/CLI standard in JTC1 based purely on user confusion, differences with the ISO C++ specification, confusion over the name, etc. No one had to demonstrate some sort of fundamental mechanical conflict between 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. <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. <br></span></div>",1] );
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.
Page Comments
<!--
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.
</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.
</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!
<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?
<br></span></div>",1]
);
//-->
<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.
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 loaded 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.
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!
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. Now we can't?
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
of precedents, since eveen last year there were contradictions raised against
Microsoft/Ecma's C++/CLI standard in JTC1 based purely on user confusion,
differences with the ISO C++ specification, confusion over the name, etc.
No one had to demonstrate some sort of fundamental mechanical conflict
between 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.
<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.
<br></span></div>",1]
);
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.