Group items tagged

This seems to me to be a turning point for the creation of global standards. Microsoft was invited to be part of the original ODF Technical Committee in OASIS, and chose to stand aside. That committee tried to do its best to make the standard work well with Office, but was naturally limited in that endeavor by Microsoft's unwillingness to cooperate. This, of course, made it easier for Microsoft to later claim a need for OOXML to be adopted as a standard, in order to "better serve its customers." The refusal by an incumbent to participate in an open standards process is certainly its right, but it is hardly conduct that should be rewarded by a global standards body charged with watching out for the best interests of all.

By Marbux posted Jun 19, 2007 - 3:16 PM Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy." I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not. I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification.

An intriguing idea is whether we can have it both ways. Suppose you are in an ODF editor and you have a "Save for archiving..." option that would save your ODF document as normal, but also generate a PDF version of it and store it in the zip archive along with ODF's XML streams. Then digitally sign the archive along with a time stamp to make it tamper-proof. You would need to define some additional access conventions, but you could end up with a single document that could be loaded in an ODF editor (in read-only mode) to allow examination of the details of spreadsheet formulas, etc., as well as loaded in a PDF reader to show exactly how it was formated.

Don't forget about HTML

February 25, 2007

HTML’s potential and actual suitability for much document interchange

In other words, I would like to lay out my printable documents in a way that’s familiar to me, for which I have tools that can support this and that can easily be changed without having to do a search and replace through a hundred distance instances of a paragraph. In short, I want CSS, acting on XHTML, generating my printed pages as readily as it displays that content to the screen. A previous blog from Michael Day about PrinceXML reminded me that I hadn’t had a chance to play with it. My previous experiences with XHTML to PDF conversion were, to put it bluntly, terrifying, and so, as I was downloading the JAR file I wasn’t expecting a lot. When I tried it, I wasn’t disappointed … I was stunned. I had taken an article that I’d recently written for XML.com and run it through Prince. It digested the ten page article and cranked out a PDF in under a second, and the quality was better than anything I’d been able to get with a straight DocBook/FO/PDF rendering. I looked up the documentation, and found that it supported the CSS 3.0 page rendering set, as well as support for columns (including columnar rules), it could be used to print SVG content embedded or linked to the main XHTML document, and it included a nice set of extension properties for handling headers and footers, internal links, rounded borders, and the full panoply of CSS selectors including nth-child (which seemingly no one supports), content search and the whole gamut of pseudo-classes.

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.

The recent bomb in the ODF world from Gary Edward’s claims that Sun successfully blocked the addition of features to ODF that would be needed for full interchange with Office are explosive not only because they demonstrate how ODF was (properly, in my view) developed to cope with the particular features of the participants, not really as a universal format, but also because the prop up Microsoft’s position that Open XML is required because it exposes particular features that ISO ODF is not capable of exposing. Both because ODF is still in progress and because sometimes the features are simply incompatible in the details.

Actually, ODF is about to get a new manifest along with the new metadata stuff. Because we base that on RDF, the manifest will also be RDF-based. It gives us the extensibility we want to provide (extension developers, for example, can add extra metadata they may need), without having to worry about breaking compatibility. The primary addition we've made is a mechanism to bind a stable URI to in-document content node ids and files. This is conceptually not all that different than what I see in OPC; it's just that the unique IDs are in fact URIs. Among other things, in the RDF context that allows further statements to be bound to those URIs. Bruce D'Arcus | July 29, 2007 01:02 PM

AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.

Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years.   Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.

Welty gave a rapid-fire look at the realities of open source in government. "The doors have been blown open in California," he said. "In 2004 when Governor Schwarzenegger signed the California Performance Review a section called State Operations #10 specifically authorized the use of open source." Operations #10 says: "Departments should take an inventory of software purchases and software renewals in the Fiscal Year 2004-2005 and implement open source alternatives where feasible."

Presentations made by Jim King of Adobe Systems

That said, it goes on to acknowledge that “there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects.

First, let me say that I am a CIO in a small (20 employees but growing fast) financial services company. I am well aware of how locked-in I am getting with our MS-only shop. I am trying to see my way out of it, but this "ODF vs ODFF" is leaving me very confused and no one is working to clear the fog. I beg for all parties to really work towards some sort of defined understanding. I don't need cooperation. But, what I don't have is well-defined positions from all parties. As it is, I feel safer staying the course with MS right now, honestly. It's what I know vs the mystery of this "open cloud" and all the bellicose infighting. How's that for "in the trenches" data? I posted a comment on Andy's blog, and I will post the same comment here for your group (minor edits): I will admit to being very, very confused by all of this ODF vs ODFF posturing. I will try to put my current thoughts in short form, but it will be a muddled mess. I warned you! From what I gather, the OpenDocument Foundation (ODFF) is attempting to create more of an interop format for working against a background MS server stack (Exchange/Sharepoint). You worry that MS is further cementing their business lock-in by moving more and more companies into dependency on not only the client-side software but also the MS business stack that has finally evolved into a serious competitive set. At that level, and in your view, the "atomic unit" is the whole document. The encoded content is not of immediate concern. ODF is concerned with the actual document content, which ODFF is prepared to ignore. The "atomic unit" is the bits and parts in the document. They want to break the proprietary encodings that MS has that lock people into MSOffice. The stack is not of any immediate concern. So, unless I misunderstand either camp, ODF is first attacking the client end of the stack, and ODFF is attacking the backbone server end of the stack. The former wants to break the MSOffice monopoly by allowing people to escape those proprietary encodings, and the latter wants to prevent the dependency on server software like Exchange and Sharepoint by allowing MS documents to travel to other destinations than MS "server" products. Is this correct? I have yet to see anyone summarize the differences in any non-partisan way, so I am at a loss and not enough information is forthcoming for me to see what's what. The usual diatribe by people closer to the action is to go into the history of ODF or ODFF, talk about old slights and lost fights, and somehow try to pull at emotional heartstrings so as to gain mindshare. Gary's set of comments on this blog have that flavor. This is childish on both sides. Furthermore, the word "orthogonal" comes to mind. I often see people too busy arguing their POV, and not listening to others, when there is no real argument to keep making. It's apple-and-oranges. ODF vs ODFF seems like they are caught in this trap. Everyone wants to win an argument that has no possible win because the participants are not arguing about the same thing. Tell me: Why can't the two parties get along? I can see a "cooperative" that attacks the entire stack. Am I the only one seeing this? Am I wrong? If yes, what's the fundamental difference that prevents cooperation?

The real technical content of the CDF recommendations is in details of how to glue these various (XML markup) languages together once they all have been processed into their respective DOMs. It establishes conventions for how a script might reach across DOM boundaries, how events might get propagated across DOM boundaries and stuff like that. I won't go into this any deeper because you will get more accurate information by just reading the W3C documents. But the main idea of CDF is to bring these variously defined content types into a uniform "framework" so that scripts can operate more at a document level instead of being confined to their own document child.

Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work

Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work That is the way quality specifications are written. For example, ISO/IEC's JTC 1 Directives (link to PDF) requires that international standards designed for interoperability "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." With that clarity, conformance is testable and can provide confidence of interoperability. A suite of tests may be developed and applied to an implementation to determine which tests pass, which fail, and hence arrive at an objective pronouncement on conformance of an implementation against the entirety of the specification.

In a quality specification, it should be feasible to select a normative paragraph, identify a conformance test for it, and make a clear statement that this test proves that an implementation meets (or fails to meet) that requirement. Call it a test plan: define the tests (test specification), define the expected set of results, and define what constitutes a "pass" of each test that establishes conformance. The plan then provides the matrix of test spec against requirement. Simple.