tag:blogger.com,1999:blog-5462488.post116846568416497827..comments2023-12-30T00:42:43.466-08:00Comments on Open Stack: Game Time for OpenDocumentAnonymoushttp://www.blogger.com/profile/10645842258906731036noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5462488.post-42917219553812900002008-02-15T06:42:00.000-08:002008-02-15T06:42:00.000-08:00When we talk aboutdata conversion india has been a...When we talk about<A HREF="http://www.e-datapro.net/" REL="nofollow">data conversion india</A> has been a great place to get those jobs done at a cheaper priceAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5462488.post-68809386324417331292007-02-01T02:53:00.000-08:002007-02-01T02:53:00.000-08:00And ACME 376 is the end-run around that.
Microsof...And ACME 376 is the end-run around that.<br /><br />Microsoft can consent to tie itself in knots explaining how da vinci won't work, while it's already up-and-running, and also how their own ODF-MSOOXML plugin will work, when it is so far behind schedule so as not to be funny.<br /><br />A good number of important and useful developments in the computer industry came about because of individuals insisting on doing things behind bosses' backs. I suspect that with this double MSOOXML hassle, the growth of Microsoft's control will cause more trouble than its worth for so many businesses that they'll look the other way when da vinci gets installed, just because they would rather have their systems working than not or intermittently.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5462488.post-13484585740552365032007-01-13T12:03:00.000-08:002007-01-13T12:03:00.000-08:00Hi arb,
IMHO, it all comes down to one question:
...Hi arb,<br /><br />IMHO, it all comes down to one question:<br /><br />*... Is ODF able to handle everything EOOXML was designed for? Is there something you can do in EOOXML that can't be done with ODF?<br /><br />Microsoft insists that the reason they developed EOOXML is that ODF is inadequate and unable to handle the advanced features of MSOffice, and, most importantly, the billions of binary legacy documents produced by the many versions of MSOffice still in production. <br /><br />The answer to this question is that ODF can handle everything MSOffice can throw at it.<br /><br />There are two ways of proving this. <br /><br />The first is to do an external mapping between an EOOXML file and ODF. This is what the MNC Translator Project tries to do using an industry standard XSLT - XPath approach. The results are interesting and instructive. They are unable to do a transform from ODF to EOOXML - which not surprisingly is their primary project objective. The XSL Transform from EOOXML to ODF is much easier to accomplish, but they are trying to do something near impossible. The reason is that EOOXML is inadequate and unable to handle the advanced presentation features (styles) of ODF applications.<br /><br />Now, be careful here with what i just said. ODF is able to handle these advanced presentation features so common to ODF ready applications, but EOOXML is not. Yet, ODF can handle everything EOOXML can do. Which is to say, everything MSOffice and the legacy binaries can throw at it.<br /><br />Another way of stating this would be to say that EOOXML is a subset of ODF. But note you can't say that ODF is a subset of EOOXML. <br /><br />The second way of proving that ODF can handle MSOffice is to mount a native MSOffice ODF plugin and start converting and producing ODF natively in MSOffice.<br /><br />This has been proven by the OpenDocument Foundation's daVinci plugin. daVinci is able to handle the entire legacy of billions of binaries, the nuances and unique needs of assistive technology add-ons, the infamous LOB's - those line of business applications developed on top of MSOffice, and the critically important day to day business processes bound to years of MSOffice use.<br /><br />These two arguments are application neutral. <br /><br />The first argument isolates the file formats from application influences and examines them purely on terms of XML. Here we find that EOOXML breaks the most fundamental promise of XML; the transformation promise.<br /><br />The second argument, an ODF plugin for MSOffice, pits the two file formats against each other within the same application. Again neutralizing the influence of application specific features.<br /><br />In their arguments to prove that ODF is inadequate, Microsoft drags us into an unfair and disingenuous application bound comparison model. What they end up arguing is that MSOffice has different features than OpenOffice. Which has nothing to do with the XML file format comparison. <br /><br />Maybe they just don't get what ODF was designed to be? Maybe after so many years of binding proprietary file formats to specific application versions, they can't see their way out of the application bound swamp?<br /><br />The truth is that ODF was designed to be an open and universal file format, application and platform independent, timeless in it's usefulness across all kinds of information domains, including those we have not yet dreamed of.<br /><br />The information domains that were considered during the ODF 1.0 phase of development include desktop productivity environments; enterprise publication, content and archive management systems; SaaS and SOA implementations (the universal transformation layer); and the Open Internet with all that the Web 2.0 can throw at it.<br /><br />The only way ODF can achieve this universal reach is to stay as close as possible to the continuing development of open standards, maintaining compatibility with both the protocols, methods and open means of implementation.<br /><br />EOOXML on the other hand was designed to meet the needs of one vendors application and platform. It is entirely bound and dependent on that vendors application interfaces and platform system calls. By design.<br /><br />Which is okay, except that now Microsoft wants the world to accept this as an approved ISO Standard - an approval that would totally contradict and introduce problematic inconsistencies with existing ISO products. That's not okay!<br /><br />If Microsoft wants to introduce EOOXML to ISO as a recognized subset of ODF, that would require some serious harmonization work between OASIS ODF TC and the MSECMA TC. That would be okay, but there is no indication that Microsoft would be willing to pursue this route. Even though Microsoft joined the original OASIS Open Office XML TC (ODF), they declined to actively participate in the work. They have however maintained their membership and observer status in the OASIS ODF TC. Observer status provides them with direct access to all documents, discussions, meetings, wiki's, listserves, sub committee work, commentaries, etc. The only thing is that they don't qualify to vote unless they actually attend the conference calls.<br /><br />The harmonizing process between ODF and Chinese UOF is under way. There is no reason why the same can't be done with EOOXML.<br /><br />Hope this helps, and thanks for the comment,<br />~ge~Anonymoushttps://www.blogger.com/profile/10645842258906731036noreply@blogger.comtag:blogger.com,1999:blog-5462488.post-1168602767578851252007-01-12T03:52:00.000-08:002007-01-12T03:52:00.000-08:00EooXML should be blocked on this basis. ODF alread...EooXML should be blocked on this basis. ODF already exists and EooXML is therefore a duplication of an established ISO standard for no good reason. The argument that it is a defacto standard is complete nonsense - nobody uses it yet. If Microsoft decided to document and publish it's binary .xls, .doc format versions as ISO standards, then there would be some justification for that because they are defacto standards, but not EooXML<BR/><BR/>If EooXML is passed, then you know there is corruption at work within ISO since they prevented the same thing being done to wapi standards by the Chinese.Anonymousnoreply@blogger.com