Group items tagged

At the onset of XML four long years ago, I commenced a jeremiad against Standard Data Vocabularies (SDVs), to little effect. Almost immediately after the light bulb moment -- you mean, I can get all the cool benefits of web in HTML and create my own tags? I can call the price of my crullers <PricePerCruller>, right beside beside <PricePerDonutHole> in my menu? -- new users realized the problem: a browser knows how to display a heading marked as <h1> bigger and more prominently than a lowlier <h3>. Yet there are no standard display expectations or semantics for the XML tags which users themselves create. That there is no specific display for <Cruller> and, especially, not as distinct from <DonutHole> has been readily understood to demonstrate the separation of data structure expressed in XML from its display, which requires the application of styling to accomodate the fixed expectations of the browser. What has not been so readily accepted is that there should not be a standard expectation for how a data element, as identified by its markup, should be processed by programs doing something other than simple display.

There have also emerged a few "horizontal" data vocabularies, intended for expressing business communication in more general terms. One of these is the eXtensible Business Reporting Language (XBRL), about which more below. Most recently, governments and governmental organizations have begun to suggest and eventually mandate particular SDVs for required filings, a development which expands what troubles me about these vocabularies by an order of magnitude.

Fortunately for Microsoft, the DaVinci plugin is coming, which will enable Microsoft office applications to comply with ISO 26300. We all understand the financial issues that prompted the push to make OOXML a standard (see Tim's comment above and http://lnxwalt.wordpress.com/2007/01/21/whose-finances-are-on-the-line/ for more on this) and ensure continued vendor lock-in. However, OOXML is not the answer.

ODF can handle everything and anything Microsoft Office can throw at it. Including the legacy billions of binary documents, years of MSOffice bound business processes, and even tricky low level reaching add-ons represented by assistive technologies.

A fatal flaw in your analysis By Marbux Posted Saturday 21st April 2007 08:15 GMT Your analysis contains a fatal flaw, Martin. That is your belief that adequate Microsoft XML <> OpenDocument translators will be available. In fact, all of the translators suck mightily and there is no prospect at all of them being perfected. The major problems are: (i) that Microsoft's XML formats seem deliberately designed to thwart their parsing with XPath, which is essential to XML transformations; (ii) that Microsoft's "XML" file formats include binary blobs, bitmasks, and multiple Windows and Microsoft dependendencies, all of which defy XML transformations; and (iii) OpenDocument assumes a richer page layout engine than Microsoft Word provides, so while DOCX can be completely mapped to ODT it is impossible to fully map in the other direction without declaring an MS Office interoperability subset of OpenDocument and ODF applications implementing a compatibility mode with reduced features. (That is more than somewhat ironic, given Microsoft's spin that it couldn't implement all of its features in OpenDocument. In fact, the exact opposite is true.) In fact, Steve Ballmer is on record as saying that the developers of the Novell-Microsoft-Clever Age plug-ins will not even attempt to achieve full fidelity file translations between the two formats. http://www.eweek.com/article2/0,1895,2050848,00.asp?kc=EWEWEMNL103006EP17A Those translators achieve at best far less conversion fidelity than existing file conversion filters between OpenDocument and Microsoft binary file formats such as the OpenOffice.org conversion filters, which achieve only about 80 per cent fidelity. The file format cognescenti know this. See e.g., the paper by Gary Edwards and Sam Hiser included in this edition of the European Journal for the Informatics Professional. http://www.upgrade-cepis.org/issues/2006/6/up7-6Hiser.pdf (PDF). (Note that I contributed to that paper.) And as also detailed in that paper, what works well enough for some of us does not necessarily work well enough for all. Anything less than full fidelity data conversions is absolutely unacceptable in the context of wholly automated business processes and is in fact illegal in various contexts, including government records. So your thesis doesn't fly. In fact, I'd go so far as to bet that you have been suckered by the Microsoft spin doctors. Another indication is your depiction of the file format wars as being waged primarily between IBM and Microsoft, a recent theme of Microsoft's public relations machine. While it is seductive to believe that the controversy is just another chapter in the war between major competitors, the pro-ODF camp is far broader than IBM. For example, nearly 20 governments recently opposed fast track processing of Microsoft's draft standard at ISO. Do you believe they were all carrying water for IBM? Government bodies in more than 50 nations have chosen to adopt ODF. http://opendocumentfellowship.org/government/precedent And dozens of developers now support the OpenDocument standard in their applications. http://opendocumentfellowship.org/applications While IBM has had a noteworthy role in proliferating the OpenDocument formats, there is a movement without a recognizable leader in the industry. When it comes to vendor influence on things relevant to ODF, Sun Microsystem's far outshines IBM. But in fact, a core group of open standards and free and open source developers and advocates -- inside and outside government -- have played a far larger role. This is a customer-driven phenomenon, not a vendor-driven effort as you portray. So I will respectfully suggest that you reexamine your position on these issues. Reasonable minds can differ, but not on the grounds you advocate.

So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact. No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a de facto Sun Microsystems standard wearing the clothing of a de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one? Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.

Sun Microsystems Inc., largely considered an avowed opponent of Open XML because of its own development and support for the competing, ODF-based StarOffice suite, found itself in the unexpected position of stating its support for ratifying Open XML -- albeit after some changes in the proposal are made.

this new draft includes Microsoft's OOXML formats as an acceptable "open format." 

This myth is rather silly if you think about it. Here is why… When people talk about interoperability and Open XML they do so primarily in the context of ODF. The story goes something like this: 1. Open XML is not interoperable with ODF 2. Open XML should be interoperable with ODF because ODF is already an ISO standard! 3. Hence: Open XML is no good, because it is not interoperable with ODF and therefore Open XML should not be an ISO standard!!!

How come I am the one to notice how deficient ODF really is?

The short version of the story so many are talking about today: A Texas judge is barring Microsoft from selling Microsoft Word due to alleged patent infringement and fining the Redmondians multiple millions as part of the case. But most synopses of the case seem to be omitting a key part of the ruling: the concept of “Custom XML.” According to the press release from the lawyers for plaintiff i4i: “Today’s permanent injunction prohibits Microsoft from selling or importing to the United States any Microsoft Word products that have the capability of opening .XML, .DOCX or DOCM files (XML files) containing custom XML.” What is “Custom XML”? Is it a (supposedly) unremo

here was strong consensus among Member State administrations on the necessity to use ODEF on "openness" being the basic criteria of ODEF and resulting requirements towards industry players / consequences for public administrations There is a general dissatisfaction with the perspective of having competing standards; One format for one purpose: Administrations should be able to standardize (internally) on a minimal set of formats; No incomplete implementations, no proprietary extensions; Products should support all relevant standards and standards used should be supported by multiple products; Conformance testing and document validation possibilities are needed -> in order to facilitate mapping / conversion; Handle the legacy / safeguard accessibility

"Open document formats: I get it! But how do I get there? Discuss."

# re: Office Open XML final draft!!! @ Wednesday, October 11, 2006 1:46 PM The past incarnations of DrawingML have been chaotic. It would be interesting, out of curiosity, to get an accurate history of what changed over time, perhaps to better understand what is supported in what. Here is my take, I am pretty sure I got at least 50% of it wrong :-) - pre-Windows 95 era, Word, Excel and Powerpoint use their own vector drawing layer used to draw shapes, pictures, diagrams, art and charts. Powerpoint, acquired by Microsoft in 1987, has by far the advanced drawing layer (bi-linear gradients, opacity, ...), codenamed Escher (in reference of the famous mathematician). - In Office 95, it is decided to reuse the Powerpoint vector graphics layer in Word and Excel. Migration begins. - Migration ends with Office 97 where both Word, Excel and Powerpoint use the same vector graphics layer, publicly known as MSO (mso97.dll) - In Office 2000, it's all craze about internet and Word tries to export WYSIWYG html. For that end, mark up extensions must be added to account for the MSO drawing layer. Hence the VML (Vector Markup language). Excel and Powerpoint don't support it. Internet Explorer natively supports VML (Internet Explorer's Direct animation vector drawing layer dismissed for performance reasons). - In Office XP, VML migration ends and both Word, Excel and Powerpoint support VML whenever a document is saved as a "Single web page archive" (.mhtml extension). - In Office 2003, nothing changes. - In Office 12, MSO gets rewritten with backwards compatibility in mind. The vector drawing layer uses more sophisticated drawing functionalities which makes it easier to draw themed, 3D realistic  objects. Technically, the differences are akin to the differences between GDI and GDI+. This new shared library is known as E2O and the corresponding mark up language is known as Drawing ML (Ecma TC45 specs). - In Office 14, ??? perhaps the drawing layer is rewritten, again, to 1) use WPF 2) to allow plugins, hence enabling much more sophisticated do-it-yourself scenarios. Use cases : custom charts ; BI analysis tools. Stephane Rodriguez

A week or so ago, I published a podcast at IT Conversation with Scott Mace interviewing Gary Edwards about OpenDocument. Edwards is the president of the OpenDocument Foundation. OpenDocument Foundation is a non-profit that works to promote the OpenDocument file format–an XML file format for office documents. There’s no question that businesses want an XML-based file format for office data. The question, naturally, is which XML-based file format. Microsoft has it’s own XML-based file format called OpenXML.