Group items tagged

OOXML on the other hand presents ISO with a very different situation. Because of the way the OOXML - Ecma charter is worded, i don't see how ISO JTC-1 could ever fix the OOXML interoperability problems. ISO approval of OOXML would include acceptance of a charter that defines and limits OOXML interoperability to whatever MSOffice determines it to be. If Patrick and the JTC-1 tried to bring OOXML into compliance with existing ISO Interoperability Requirements, they would have to somehow amend a charter duly approved.Given that the JTC-1 has yet to address a two year old ISO directive regarding ODF interop compliance, what are the odds they will dare to amend an approved charter? Not good i think.ISO approval of OOXML is a tragedy for all of us. For sure it's the end of ODF. It's perhaps the end of ISO as a respected standards organization. The issue of open standards itself will become a joke, with the reality of standards by corporation having us all wringing our hands in despair.

ISO/IEC 26300:2006 XHTML version 1st Information technology -- Open Document Format for Office Applications (OpenDocument) v1.0 XHTML version

The following standards are made freely available for standardization purposes. They are protected by copyright and therefore and unless otherwise specified, no part of these publications may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, microfilm, scanning, reproduction in whole or in part to another Internet site, without permission in writing from ISO. Requests should be addressed to the ISO Central Secretariat.

ISO/IEC 29500-1:2008 Electronic inserts 1st Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 1: Fundamentals and Markup Language Reference JTC1/SC34 ISO/IEC 29500-2:2008 Electronic inserts 1st Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 2: Open Packaging Conventions JTC1/SC34 ISO/IEC 29500-3:2008 1st Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 3: Markup Compatibility and Extensibility JTC1/SC34 ISO/IEC 29500-4:2008 Electronic inserts 1st Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 4: Transitional Migration Features JTC1/SC34

There are really two central catalysts for these actions. One of these is the feedback we have received from the regulatory environment. There is a high degree of interest in our working with other software vendors to improve information exchange through the use of standardized technologies.

In our early testing we are observing that every product implementing these standards has some level of variation from the written spec. If you've been around standards for a while, you'll know this is common, and requires dialog to establish best practices & patterns. This is our reason for joining the OASIS, AIIM and ISO committees,

Because ODF side-stepped the compatibility question, we were left to solve (continue solving) that challenge elsewhere; the aversion to dealing with legacy content created a real problem for customers who want to transition to more open file formats.

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.

Both ODF and OOXML are only one WTO Dispute Resolution Process complaint away from losing their international standard, national technical regulation, and government procurement specification status. They do not meet the minimum requirements of international law. Both are unnecessary obstacles to international trade; neither specify a uniform and substitutable product. That does not sound like a sound business plan to me. So I return to my question posed in an earlier post: Will ODF v. 1.2 under your leadership attempt to "clearly and unambiguously specify that conformance requirements essential to achieve the interoperability" and will the standards-based interoperability between *different* IT systems be "demonstrable," as required by JTC 1 Directives? That is not a complicated question and it requires no deep dive into international law to answer. International law requires what the quoted JTC 1 Directives require in this regard, but for purposes of the point under discussion we need go no further than the Directives' plain language. One either adheres to the rules or one forfeits the moral high ground to complain when others ignore the rules. Where does Rob Weir stand on complying with the rules?

ISO is bound to the business of "interoperability", and has very strict guidelines for interoperability requirements, that are themselves tied to international trade agreements and legal conventions. In this context, it is beyond surprising that ISO allows the "OASIS PAS" and "Ecma Fast Track" channels to remain open, with specification work remaining under the controlling influence of the vendors.IMHO, the change in Patrick's position is entirely due to the realization that it is impossible to map between OOXML and ODF. I don't know this for sure, but when i read the German Standards Group (DIN) report on harmonization, authorized by the EU-IDABC and provided to ISO, i couldn't help but wonder how Patrick would react. The report definitively ends his OOXML ODF mapping dream.

The proposed discussion list name is "oiic-formation". (2) A preliminary statement of scope for the TC whose formation the list is intended to discuss. It is the intent of the ODF Implementation, Interoperability and Conformance (IIC) TC to provide a means for software implementors and service providers to create applications which adhere to the ODF specification and are able to interoperate. As such, the purpose of the IIC TC includes the following:

It is the intent of the ODF Implementation, Interoperability and Conformance (IIC) TC to provide a means for software implementors and service providers to create applications which adhere to the ODF specification and are able to interoperate. As such, the purpose of the IIC TC includes the following: 1. To publish test suites of ODF for applications of ODF to check their conformance with the Standard and to confirm their interoperability; 2. To provide feedback, where necessary, to the ODF TC on ways in which the standard could improve interoperability; 3. To produce a set of implementation guidelines; 4. To define interoperability with related standards by the creation of profiles or technical reports; 5. To coordinate, in conjunction with the ODF Adoption TC, OASIS InterOp demos related to ODF; The IIC TC may also liaise with other standard bodies whose work is leveraged in present or future ODF specifications. These include, but are not limited to, the W3C and ISO/IEC JTC1/SC34.

1. To publish test suites of ODF for applications of ODF to check their conformance with the Standard and to confirm their interoperability; 2. To provide feedback, where necessary, to the ODF TC on ways in which the standard could improve interoperability; 3. To produce a set of implementation guidelines; 4. To define interoperability with related standards by the creation of profiles or technical reports; 5. To coordinate, in conjunction with the ODF Adoption TC, OASIS InterOp demos related to ODF; The IIC TC may also liaise with other standard bodies whose work is leveraged in present or future ODF specifications. These include, but are not limited to, the W3C and ISO/IEC JTC1/SC34.

Opponents to OOXML, which include IBM (Quote) and the Open Document Foundation, have argued that Microsoft's specifications are unwieldy and that the standard application is redundant with the Open Document Format (ODF), which already exists. Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address different needs in the marketplace," the company wrote in an open letter published earlier this month.

The issue we were discussing -- and what I believe the ODEF conference was very much concerned with -- was whether ODF plus vendor-specific extensions will be classified as conformant ODF. The market requirement is for "Exchange Formats" and document-level interoperability. I could repose my question as whether ODF v. 1.2 will "clearly and unambiguously specify interoperability requirements essential to achieve the interoperability," as required by JTC 1 Directives. As you noted in an earlier post in this thread, you can't do interoperability if you use vendor extensions. > I see a standard as providing a shared vocabulary for buyers and sellers > to express their requirements. You are in error. This is a matter controlled by law rather than by personal opinion. Standards are all about the substitutability of goods, weights, and measures. A standard specifies all characteristics of a product, weight, or measure in mandatory terms so there is uniformity. Standards are the antithesis of product differentiation. Their very purpose is to eliminate product differentiation.

So I think users need to understand, very clearly, that an ODF document/app of *either* conformance class has an EXTREMELY WEAK CLAIM TO INTEROPERABILITY. The "pure ODF conformance" sticker would be at best valueless and at worst positively misleading. So what I'd like to see is some real effort from the TC going into resolving this problem ...

Standardization by Corporation Maybe i spoke to soon. This just came in from ISO, the resignation letter of the SC34WG1 Chairman who has completed his three year term. There is a fascinating statement at the end of the Martin Bryan letter. "The disparity of rules for PAS, Fast-Track and ISO committee generated standards is fast making ISO a laughing stock in IT circles. The days of open standards development are fast disappearing. Instead we are getting “standardization by corporation”, something I have been fighting against for the 20 years I have served on ISO committees. I am glad to be retiring before the situation becomes impossible..." When corporations join open standards or open source efforts, they arrive with substantial but most welcome financial and expert resources. They also bring marketshare and presence. And, they bring business objectives. They have a plan. As long as the corporate plan is aligned with the open standards - open source community work, all is fine. In fact it's great. For sure though there will come a time when the corporate plan asserts it's direction, and there is possible conflict. At this point, the very same wealth of resources that were cause for celebration can become cause for disappointment and disaster. One of the more troubling things i've noticed is that corporations treat everything as a corporate asset to be traded, bartered and dealt for shareholder advantage and value. This includes patents and interoperability issues which not surprisingly are wrapped into open standards and open source efforts. Rather than embrace the humanitarian – community of shared interest drivers of open standards and open source, corporations naturally plot to get maximum value out of the resources they commit. A primary example of this is Sun's use of OpenOffice, ODF, and an anti trust settlement disaster that left them at the mercy of Microsoft.

Where can we expect challenges?

There can be no doubt that OOXML, as a standard, has severe flaws.   It is incomplete, platform specific, application specific, full of contradictions, fails to adhere to existing standards, untestable, and presents a moving target for any IT worker.  There is not an organization in existence, including Microsoft, that promises to actually implement the full standard.  Much of this is due to the fact the final version doesn't actually exist on paper yet, but a large fraction is also do to the patchwork nature of the product. The reason governments and companies wanted a 'office apps' standard in the first place was to release an avalanche of data from aging applications.  OOXML shows every appearance of being created to prevent this escape, not enable it.   The immaturity of the standard means that it remains a gamble to see if older documents will remain readable or not.  The lack of testing means there is no way to determine what docs actually adhere to it or not.  The ignoring of existing standards guarantees compatibility problems.  All of these factors are handy for the owner of the biggest share of existing documents, as it forces users to continue to use only _their_ application or risk danger from every other quarter.

ISO International Organization for Standardization Document #: ISO/IEC FDIS 24754  Title: Information technology -- Document description and processing languages -- Minimum requirements for specifying document rendering systems  Scope:   Keywords: IT applications in information, documentation and publishing  Committee: ISO IEC JTC 1 SC 34 - Document description and processing languages  SDO Approval Date:   ANSI Approval Date:   Date File Updated in Database May 13 2008 4:50PM 

DOUG MAHUGH, program manager for ISO 29500-based products, Microsoft: One thing to be very clear about here is this: When we say, "support for ODF in [Office] SP2," we intend to write very compliant ODF documents when you save a document. However, it's not a given that everything you can do in the Office UI is savable under ODF. As you're alluding to, there are things -- SmartArt, conditional formatting, things like that -- that we have in Office and that are popular features, where there is no way to save those in ODF, currently.The way we're approaching that, I can share a little bit with you: We're not throttling the UI, as you describe, where certain things are disabled. Rather, at the time you save, we're telling you, "Hey, you're saving in this other format; some information in this document may be lost." That sort of thing. And let me tell you why we made the decision to do it in that particular way: There are situations where some of that functionality may be very useful to the user, even though it can't be serialized out to the format that they're saving in.

The engineering decisions that were made in the original creation of ODF represent the engineering pathway and the innovations that were happening in the OpenOffice space. The engineering decisions and development pathway for Open XML represents that which was happening in [Microsoft] Office, and the feature sets are not in parity. In fact, there's a superset of features within the Microsoft Office set, but there are certainly features that are exclusive to OpenOffice that do not get covered in Microsoft Office.

We really hope to see ODF move to JTC 1 / SC 34 maintenance