[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [opendocument-users] simple OO.org document goes awry in MS Office 2007 w/SP2 - what went wrong?
On Fri, Jun 19, 2009 at 12:12 AM, <email@example.com> wrote: > marbux <firstname.lastname@example.org> wrote on 06/19/2009 05:51:19 AM: >> Please point me to all those interop defect reports IBM has filed >> against the specification, Rob? I'm apparently suffering a huge memory >> loss. Not. And even though we deal with a hypothetical situation >> rather than reality, aren't you presupposing that the TC would adopt >> the same solution for the problem that you've implemented in your app? >> I can already hear the cries like KDE's that if the spec doesn't >> permit a choice between ordered list tuples and ordered list triples >> they'll have to write a converter for their legacy documents. >> > > For example, the major theme of ODF 1.1 was accessibility, aka > interoperability with screen readers for blind users. IBM took a leading > role in analyzing the specification to find problems in this area and > proposing fixes. Score 1 for IBM after a scandal in Massachusetts that couldn't be ignored. . And the next IBM interop proposal resulting from user feedback was ...? > We're certainly aware of interoperability issues in Symphony, but our > analysis shows that they are either implementation defects or > specification ambiguities that are already known and fixed in ODF 1.2. I thought Symphony wrote ODF 1.1, Rob. Where are the corresponding proposals to fix ODF 1.1 and IS 26300? And if the spec was so clear and unambiguous, how did IBM manage to get it wrong to begin with? And why the lack of concern over the spec saying, "There are no rules regarding the elements and attributes that actually have to be supported by conforming applications, except that applications should not use foreign elements and attributes for features defined in the OpenDocument schema?" Oh, that's right. "Should not" creates a conformance requirement in your book, right? Was that why you were accusing Microsoft of non-conformance? > I'm looking at this very pragmatically, Paul. Can't seem to find "pragmatically" in the Agreement on Technical Barriers to Trade or JTC 1 Directives, Rob. Got a cite? Let's do what is necessary > to improve interoperability, without any presumptions of who or what is to > blame. I'm not adverse to improving the specification if that is where > the problem is. Rob, there's a huge disconnect between your last statement and your historical conduct. Your deeds speak louder than your words. You have no work plan to cure the underspecification problems in ODF. You are not leading the ODF TC to cure such problems, leaving the TC in a leadership vacuum, hell-bent on pumping out yet another grossly under-specified version of the spec. But in practical terms, only code can exhibit > interoperability problems, since users only run code. Sorry, but isn't this the same guy who argued on the Fellowship list until he was blue in the face that the JTC 1 Directives only required that interoperability be demonstrable from the provisions of the spec rather than demonstrated? Do I have to dig for those links to show yet another instance of Rob Weir reversing positions whenever it's helpful to his latest argument against fully specifying the ODF standard? > So I think an > approach, like used at the Plugfest, where we concentrate on user-facing > scenarios and determine the source of the error and address that error. > This is an engineering-based approach. No. It's an approach for keeping the specification dark and mysterious in defiance of the law and market requirements for standard-based interoperability, propped up with "trust the big vendors to do the right thing" excuses. Like I've said on other occasions, IBM has had 53 years to lead us out of the word processor vendor lock-in wilderness and it still steadfastly resists even the creation of an open, fully-specified standard. Let the vendors work it out app to app? No sir. I want my standard fully specified and out on the table where anyone can use the spec to compete. The big vendors have had decades to show that application-level interop work can produce interoperable word processors. In my book, when plain text XML came along, the big vendors couldn't rely anymore on trade secret, moving target, binary formats to maintain their vendor lock-in / lock-out games. The successor tactic is grossly underspecified XML standards, accompanied by loud and false claims that they are "open standards." But they are standards in name only. Standards are about uniformity, about the substitutability of products in a market defined by a standard. Standards are about leveling the competitive playing field by specifying [i] "any objectively definable 'features', 'qualities', 'attributes', or other 'distinguishing mark'" [ii] of an identifiable product or group of products [iii] only in mandatory "must" or "must not" terms. WTDS 135 EC - Asbestos, (World Trade Organization Appellate Body; 12 March 2001; HTML version), para. 66-70, <http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm> reaffirmed, WTDS 231 EC - Sardines, (World Trade Organization Appellate Body; 26 September 2002), pp. 41-51, <http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds231_e.htm>. All IBM has come up with these many years has been: [i] excuses that are beyond lame for keeping ODF under-specified; [ii] personal attacks usually with a "Microsoft shill" paint brush on people who dare suggest that ODF is in desperate need of repair so that it can become a universal standard; and [iii] excuses for keeping OpenOffice.org at the center of the ODF universe rather than the standard. In the latter regard, it has not escaped my notice that IBM uses the OOo code base in its own products and acquired the rights to use the OOo 3.x code base in its proprietary apps notwithstanding that others are limited to the LGPL. Whereas IBM earlier worked with the OOo 1.4 code base that was dual-licensed to allow use in proprietary apps, IBM now tells us that it is implementing OOo 3.x code. <http://www-03.ibm.com/press/us/en/pressrelease/25912.wss>, with the transition to that code base scheduled for release in the second half of 2010.<http://www.ferris.com/2009/01/20/lotus-symphony-hard-to-see-why-it-will-succeed/>. So I see a rather huge conflict of interest in you as an OASIS agent cloaked with that organization's authority working to keep the ODF spec dark and mysterious whilst simultaneously pushing to use OOo as the ODF reference implementation in lieu of fully specifying the standard. > > You, on the other hand, seem to be advocating an approach that merely > mandates interoperability and then assumes that the problem goes away. But > it doesn't work that way. Straw man argumentation. I've never said anything of the sort. Whether interoperability is mandatory or > voluntary, the engineering effort required to achieve interoperability is > exactly the same. Changing 1,000 should's to shall's accomplishes exactly > nothing for the user. Oh really? Let's see, "shoulds" can be safely ignored without affecting the vendor's right to claim conformance. Changing "shoulds" to "shall" means those vendors can no longer validly claim conformance unless they obey the "shall." So "shall" puts all implementers doing the same whilst "should" invites deviation. Deviation being the enemy of interoperability, I find you in error, Rob. In fact it is far easier to get vendors to agree to > change a should to a shall after they have changed their code (or at least > committed to changing their code) than to make a change in the standard > that will automatically leave every implementation non-conformant. So > again, the emphasis on finding the practical interoperability problems via > user-facing scenarios, finding the source of the interoperability problem, > agreeing on a solution, and implementing the solution. Implementations wagging the standard at best, Rob. At worst --- what we've got --- is vendors making excuses for not getting started on fixing a badly broken spec. What you always ignore is the fact that specifying the conformity requirements that are essential to achieve interoperability is a minimum legal requirement for IT standards, a non-optional feature if you will, that must be in place before the standard is adopted. You pretend it can be put off in perpetuity, justifying it by what other people have gotten away with. But all the while your company is there before DG Competition seeking an order that Microsoft disclose Office/Sharepoint data formats and communications protocols with sufficient specificity to place competitors on an equal footing with Microsoft's own apps. Not plugfests; specifications. Not someday; ASAP. Not whiney excuses, disclosure. No matter how you cut it, it's a double standard, Rob. What would your lawyers say if Microsoft's lawyers said, "we'll just designate Office and Sharepoint as reference implementations and convene some plugfests. Now go away and stop bothering us." I think your problem is that Sun and IBM have got a whole bunch of users locked into the OOo code base and want to keep things that way by keeping the ODF spec dark and mysterious. That diagnosis is based on deeds, Rob, not on your words. It's how it looks from here. Best regards, Paul E. Merrell, J.D. (Marbux) -- Universal Interoperability Council <http:www.universal-interop-council.org>