[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Interoperability versus Conformity
On Mon, Jun 9, 2008 at 8:45 PM, <robert_weir@us.ibm.com> wrote: > > Paul, this is not JTC1, I didn't say it was. But you quoted from the same page of JTC 1 Directives in this conversation yourself, although you identified your quotation as "ISO lingo" rather than citing to the Directives you quoted from: . <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00024.html>. More importantly, are you excluding at the outset that the proposed TC's deliverables would not be submitted to JTC 1 for approval as an international conformity assessment procedure? The page we have been quoting from is inextricably intertwined with JTC 1 Directives requirements for conformity assessment procedures. If the work of this proposed TC is to acquire no status beyond that of an OASIS standard, the ODF international standard is left without formally approved conformity assessment procedures. and the proposed TC cannot change a single line of > the ODF standard. So I think the vast majority of your concerns are > misdirected in terms of the present discussion. In particular, rewriting > ODF in terms of CDF is most certainly out of scope for this new TC. The preliminary statement of scope for this proposed TC includes these three clauses: "2. To provide feedback, where necessary, to the ODF TC on ways in which the standard could improve interoperability; ... "4. To define interoperability with related standards by the creation of profiles or technical reports; ... "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." <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00001.html>. Moreover, you said in this same thread, "Remember, none of this changes conformance at the level of any of the ODF standards. *But a profile is a standard, and can define its own conformance."* <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00067.html>. So I do not see it as a valid criticism when you say that "the proposed TC cannot change a single line of the ODF standard." Of course we may not countermand existing conformance requirements in the ODF standard. But there are virtually no conformance requirements in ODF beyond the requirement of validation against the schema after all foreign elements and attributes are removed. Unfortunately, that conformance requirement is inadequate as an interoperability assessment method. Because the validation occurs after the removal of all foreign elements and attributes, the ODF validation process itself is inadequate as an interoperability conformance assessment methodology. All major ODF implementing editors generate application-specific foreign elements and attributes. The ODF validation procedure does not test real world documents because the foreign elements and attributes are stripped before validation. See e.g., <http://en.wikipedia.org/wiki/Validation>. ("Validation against an incomplete or insufficient set of criteria can lead to a state of 'validated; where 'validated' does not confer the confidence that the term intends. Thus validation of the validation criteria is an important aspect that is often overlooked.") A validation procedure that strips all application-specific extensions to the formats in effect strips many interop breakpoints before the document is validated and is therefore inadequate as an interoperability assessment methodology. I.e., is not that fact the very reason for this proposed TC? I do not see that anything I raised is outside the preliminary statement of this proposed TC's scope. Perhaps you might crank up from only a general reaction to offer specific criticisms of my proposed action plan? Is it not understandable? Do you see any technical weakness in it? Do you have an alternative action plan to actually achieve interop? I am not wedded to my action plan, but I am aware of no other efficient roadmap that is technically feasible for actually achieving it within the context of ODF implementations. If you have your own concrete proposal for achieving interoperability, I'm all ears. I want to see a well developed recipe for achieving interoperability. You may well have a better plan. But I urge you to disclose it if you do have one. We've discussed your plans for this TC on the OpenDocument Fellowship list at some length. I have made no substantial progress in understanding your goals for this TC despite our extended discussion. Are we here just to create the appearance that someone is working on ODF implementation interoperability or to actually achieve interop? Moreover, what I have quoted from the TC formation email announcement above is a "preliminary statement of scope for the TC whose formation the list is intended to discuss." <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00001.html>. Are you freezing the scope of this TC to the preliminary statement of scope? My impression is that part of the purpose of this list is to refine the preliminary statement of scope as needed. Am I wrong about that? > But I'm all in favor of looking at what other groups have done, including > the W3C, in the area of interoperability. I sent out some links earlier to > some of their practice papers and work in test case generation. Good. To be more specific, are you in favor of looking at the W3C Compound Document by Reference Framework as a candidate method of working our way past the interop hurdles in the ODF standard? That's a straightforward question requiring only a "yes" or "no" answer. But please feel free to elaborate. > Remember, ODF exists. It is an OASIS Standard. It is an ISO Standard. It > is supported and implemented by all the major players in this industry, > including IBM, Google, Sun, Microsoft, Novell, Corel, as well as several > important open source projects (and apologies to everyone I missed). The > question before us is how to improve interoperability in the world that > exists, not to continually lament that world and pine for one that does not > exist. Are we not here to actually achieve interoperability? Do we not share interoperability as a goal? Are we here for any purpose other than to make interoperability happen? Are we not both pining for a world that does not exist where office apps are interoperable? I am not here to lament. I submitted a specific and affirmative action plan to actually achieve interoperability. Are you saying it is impossible to achieve interoperability? If so, why should anyone bother participating in this proposed TC? > > I'm not here to fail. I'm not here to tilt at windmills. I'm here to apply > my engineering know-how and work with other enthusiastic and talented > volunteers to move ODF interoperability forward one small step at a time. How? What is the IBM action plan? What is its methodology? What are its milestones? If I am going to shell out the bucks to renew my OASIS membership, I want to see a TC charter that is far less vague about goals and milestones. We are in this interoperability mess precisely because ODF 1.0 slid through JTC 1 without adhering to the Directives requirement of "clearly and unambiguously specifying the conformity requirements essential to achieve the interoperability." I chased you many times around the mulberry bush before satisfying myself that IBM had no plans to add such conformity requirements to ODF 1.2. You said: "As for your question, you asked whether I will "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? "To that I can say that we are rewriting the conformance clauses in ODF 1.2, per OASIS requirements. I believe this also accords well with the JTC1 requirements. *But honestly, I also believe that what we have in ODF 1.0 also complies with JTC1 requirements.*" <http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/007361.html>. But not well enough for implementers to achieve interoperability without resorting to information outside the standard, eh? Otherwise, what is the purpose of this proposed TC? Rob, from the few clues you have offered since you proposed the first ODF Interop Camp I have come to suspect that the difference in our respective public positions on interoperability boil down to the distinction between application-level interoperability and document level interoperability. See <http://www.universal-interop-council.org/glossary/term/2> and <http://www.universal-interop-council.org/glossary/term/70> respectively. You seem to push for the former while I push for the latter. They are both technically sound approaches to achieve interoperability. But in document format standards work, only document-level interoperability work is lawful. Application-level interoperability is lawful outside the standards context, except when one player has a market power position, e.g., the court-mandated disclosure of interop specifications in Commission v. Microsoft and U.S. v. Microsoft.. From an economic standpoint, it is an issue of who controls interoperability, of who controls the substitutability of products. At the extremes, with application-level interoperability the vendor with market power controls whose applications are permitted to interoperate because the vendor is free to embrace, extend, subset, trash conforming markup, whatever. With document-level interoperability, everything needed for anyone to implement the standard and for their implementation to interoperate is contained in the standard itself. The control of interoperability passes from the vendors to the standard. Interoperability is no longer a commodity that vendors can sell or trade. Dropping down to a more granular level in the context of mega-specifications like ODF and OOXML, if lossless round-trip interoperability cannot be achieved between less and more featureful implementations, the effect of enabling only application-level interoperability is to cement current market leaders in place by denying round-trip interoperability to developers of less featureful implementations. It is a "barrier to market entry" in economic and antitrust terminology, an "unnecessary obstacle to international trade" in the terminology of the Agreement on Technical Barriers to Trade. It is a question of who controls the market; is it the entrenched big vendors through under-specification of a standard or is it the standard that specifies conformity requirements essential to achieve the interoperability? The W3C Compound Document by Reference Framework is designed to not only allow but require the interoperability of less and more featureful applications through profiles and mandatory compatibility modes in the more featureful implementations. ("A conformant user agent of a superset profile specification must process subset profile content *as if it were* the superset profile content.") It is a pro-competitive solution to a serious interoperability barrier. More importantly, from what I can see it was specifically designed for the relevant purpose (with IBM's full participation) by the acknowledged leader in XML markup languages, the W3C. Am I wrong? Or are we here to reinvent the W3C interop wheel for compound documents? You said before in discussing the subject of specifying interoperability conformity requirements in ODF itself that: "I see a standard as providing a shared vocabulary for buyers and sellers to express their requirements. Some users, like IDABC will seek applications that do not extend ODF. ODF should provide a way of expressing the technical side of that requirement. Other users will have stricter requirements." <http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/007307.html>. While I strongly disagree that such a view of an IT document format standard is either lawful or in accord with the ODF TC's charter (a "standard for office document processing and *interchange*"), my question might be posed as to how this proposed TC intends to deliver what IDABC and the other EU government bodies laid down as the problems they expect industry to solve at the Open Document Exchange Formats Workshop 2007 and the Advancing eGovernment Conference? <http://ec.europa.eu/idabc/en/document/6474>, see particularly, <http://ec.europa.eu/idabc/servlets/Doc?id=27956> ("Free the documents from the software used to create them"); <http://ec.europa.eu/idabc/servlets/Doc?id=27865> ("interoperability comes from data not from applications"); <http://ec.europa.eu/idabc/servlets/Doc?id=27862> ("Separation of document format and application"); <http://ec.europa.eu/idabc/servlets/Doc?id=27866> ("Problems with vendor specific subsets/ super sets of standards [and] optional elements within a standard"). Will this proposed TC deliver what IDABC and the other government bodies require? I offered a concrete action plan for doing so. What is IBM's action plan for fulfilling the same market requirements using what you term as the ODF "shared vocabulary" for buyers and sellers to specify their requirements? Or is that there no IBM action plan for fulfilling such market requirements or that IBM has a plan but you are not authorized to reveal it? I am not the only one pining for a world that does not exist. Rob, I was a participant when the budding computer industry first successfuly commercialized electronically automated word processing in the daily newspaper industry by embracing and extending the 6-bit Teletypesetter "TTS" standard. I well remember when "markup" was a de facto standard of handwritten symbols used to assign formatting instructions for folks who set type in molten lead. And I've been watching closely and waiting for an interop solution ever since. By my count, the big vendors have had about 40 years to demonstrate their ability to create a word processing format standard designed for interoperability of competing implementations. That is how long the big vendors have kept us locked into their own word processing products. In all that time, I've acquired a bit of cynicism. From my experience, the big vendors have had no solution to the office productivity software interop problem; I am now firmly convinced that they *are* the interop problem. It is the policies of the big vendors that pose the real interop barrier. The technical barriers pale in comparison. And I see no substantial improvement in the fact that multiple vendors distribute their own clones of OpenOffice.org, particularly when a single vendor holds the key for that code base and is also contractually bound to stand aside if and when Microsoft decides to unleash its patents on OpenOffice.org. <http://www.sec.gov/Archives/edgar/data/709519/000119312504155723/dex10109.htm>. Incremental improvement in interoperability is not an action plan, Rob; it is an excuse for not having one. You are a software architect; show me your blueprints, please. Please show me that this proposed TC will be any different from the ODF TC when it comes to interoperability. Please convince me that the agenda this time around really is the achievement of interoperability, something far less nebulous than "incremental improvement." If you do that, you will have my support. Brushing aside a proposed action plan to achieve interoperability without offering IBM's own action plan is not getting off to a good start. If IBM has a better plan, let's hear it, Rob. How does IBM propose to get us from the present mess to an ecosystem of competing but interoperable applications? I've offered one road map. What is IBM's? The ODEF Workshop identified one of its "expectations on software vendors" as "transparency of future plans of software vendors." <http://ec.europa.eu/idabc/servlets/Doc?id=27865>. I think that this would be a good time for IBM to begin fulfilling that expectation. IBM either has an action plan for this proposed TC to achieve the interoperability of ODF implementations or it does not. Brushing aside a concrete proposal with the excuse of "incremental improvement" does not convince me that IBM has any serious intention of fulfilling the interoperability market requirement within my remaining lifetime. Fifty years of vendor lock-in has been 50 years too much for me. What I am looking for here, Rob, is an IBM commitment to making ODF interoperability actually happen with a concrete plan for achievement that I can look at before I decide whether to plunge myself back into committee work. I remain fully sensitive to the fact that you likely do not have the power to set IBM policy on many relevant matters, so none of this is aimed at you personally. At the same time, still wearing the scars from having banged my head repeatedly against the ODF TC's interop stone wall, it's going to take a strong signal that IBM and Sun policy has changed in regard to ODF interoperability before I would advise anyone to take this proposed TC seriously, particularly when the ODF TC remains in a position to undo any interop profile work done on this TC by changing ODF conformance requirements itself.. Which reminds, why is a separate TC necessary? Wouldn't it make more sense to amend the charter for the ODF TC itself to do the work of this proposed TC? > This is the price of success. If ODF had failed, then no one would care > about interoperability. If ODF had few implementations or little vendor > support, then none of this would matter. But with recent announcements in > the industry, ODF is positioned now to be the most-widely deployed document > format around, supported by every major word processor, spreadsheet and > presentation graphics package on every platform. The success in adoption of > ODF, around the world, coupled with the strong user demand and subsequent > vendor support makes interoperability work more important now than ever. > We're only having this discussion because ODF won. In my humble opinion, it is far too early to pronounce victory, particularly when ODF and OOXML remain standards in name only. Both are too amorphous to be used for document interchange work. I.e., if you want OOXML interop, everyone uses the same version of MS Office. If you want ODF interop, everyone uses the same version of OOo or clone thereof. For the software users of the world, it's still a choice between whose code base you prefer to be locked into. According to my tea leaves, the winner will be the first specification that demonstrates document-level interoperability among competing information technology systems. As was said at the ODEF Workshop: "There is no functioning market." <http://ec.europa.eu/idabc/servlets/Doc?id=27866>. Best personal regards, Paul -- Universal Interoperability Council <http:www.universal-interop-council.org>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]