[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] The importance to users of documents looking the same
On Wed, Jun 18, 2008 at 3:04 PM, Hurley, Garry (L&I - OIT) <ghurley@state.pa.us> wrote: > Paul, > > I don't want to get on your bad side here, but CDRF specifications sound like they are beyond the scope of this discussion list, which was, I thought, to determine whether or not a TC needed to be formed and to write a charter. Suggesting that the TC consult the CDRF specifications as a guideline is all we should really do at this point - unless we decide that no TC needs to be formed, then I assume the standards process would fall upon the shoulders of OASIS in general. Rob, am I off-base here? You are not on my bad side Garry and I appreciate your candor. I have high confidence that if you had shared my experience working on the ODF TC as a pro-interoperability advocate and had already immersed yourself in the very considerable interoperability barriers posed by the existing specification, you would be every bit as concerned as I am that this TC's hands be died strictly to the goal of actually achieving the development of profiles and identification of an interoperability framework for creation of the profiles that enables interoperability among and between implementations of different profiles. My CDRF proposal in essence raises the questions of whether: [i] this proposed TC will be tasked with actually achieving enablement of interoperability of the kind just mentioned; or [ii] whether this proposed TC will serve only the needs of the big vendors to talk about interoperability while not actually enabling it. I ask whether there is anything in this proposed TC but more big vendor interop smoke and mirrors. We only discuss ODF interop on this formation list because the ODF TC had a loosely worded Charter that left room for its work to be non-interoperable. I care mightily whether this TC's charter is based only on trust of the big vendors that will control it or on a tightly-defined mission statement that requires the proposed TC to actually enable the means of interoperability among different IT systems of varying capabilities. I have the only feasible proposal on the table that actually requires the big vendors who will control the proposed TC to actually deliver interoperability. I have waited four decades for interoperable word processing editors and for the interoperability of smaller apps with the word processors. My trust in the big vendors who have denied the market interoperability in all that time is precisely zero. I have no interest in participating in a TC with IBM and Sun that does not resolve such issues before the work begins. I have scars all over my head from butting against the anti-ODF interop policies of Sun and IBM during my work on the ODF TC. My proposal asks that they commit to walking the interop walk rather than just talking about interop as they have in the past. I seek a sign of sincerity from the big vendors , a commitment to interoperability, a commitment to ending vendor and application lock-in. That is what my CDRF proposal is all about. The IBM resistance to my proposal and its expressed preference for leaving it up to the TC to decide whether to use CDRF or any other interoperability framework in a loosely defined Charter is sufficient to me, even ignoring other IBM positions taken in this meeting, to convince me that nothing has changed in IBM's anti-ODF interop policy. No one else has proposed a work plan that unambiguously identifies the goal of the proposed TC as actually making ODF interop feasible. I raise the issues of trust and commitment. > I admire your passion for CDRF, and if it is a viable standard, good luck in getting it past the group. I am, however, constrained to point out that my email messages are limited to about 2 MB in length and what attachments are acceptable are also limited in length. (You should see what we have to do to distribute a file to our colleagues!) Anyhow, your emails do tend to be lengthy ones, as do mine. I would really like to stick a fork in the argument of tying down a TC's options too firmly. Yes, they should be given a general purpose, and a starting point. That is all we should do. Personally, I prefer to look at this from a developer's viewpoint. "Give me the standard, tell me what has to go into the file, how to arrange the data, and the name of the file and I will give you the file with everything in its place." Let's work on getting the TC what they need to deliver those standards to me, okay? This group was not tasked with creating a standard, just desciding whether or not we need a committe to decide it, and what that committee's responsibilities will be. Judging from the traffic on the list, I would say yes, we need one. Now, how much freedom do we want to give them to develop these standards? > Rob, or anyone for that matter, do you disagree that we need a TC? Do you agree or disagree that we need to have some guidelines for them to follow? I saw a proposed skeleton for guidelines put forth earlier. I put forth several tasks earlier. I humbly suggest we all decide what additional tasks we are going to place on the list for the TC. I strongly suspect that your preference for not tying down the TC's options assumes undeserved trust of the folks who never got around to dealing with interoperability issues in the six years of the ODF TC's existence. You merely assume their trustworthiness without sufficient information to arrive at an informed opinion of their trustworthiness. It is technically impossible for this TC to create profiles for interoperable implementations of ODF without breaking compatibility with the ODF standard. ODF is riddled with application dependencies. Were there any serious intent for the proposed TC to actually deliver such profiles, a break with ODF is unavoidable. One may not make a silk purse from a sow's ear. The need for this proposed TC depends on its goals. If the goal is both interoperability and compatibility with ODF, there is no need for this TC because this TC is not the master of the language used by the ODF TC to specify ODF. With those goals, the legally appropriate place for the work to be done is on the ODF TC or a new subcommittee thereof. Specifying conformity requirements essential to achieve interoperability is by law the responsibility of the ODF TC. If the goal is both interoperability and compatibility with the ODF TC's work, the proper place for an advisory committee is a subcommitte of the ODF TC, not a separate TC. With those goals, this TC invades the turf and legal responsibilities of the ODF TC. If on the other hand the goal is to begin the work on a new standard designed for interoperability that uses ODF as a rough guide but breaks compatibility with it, then there is a legitimate role for a separate TC for the profile work and testing of conformance with them. The twin goals of interoperability and compatibility with the ODF standard can only be fulfilled by the ODF TC. The ODF TC has been uninterested in doing the necessary work and producing a specification designed for the interoperability of implementations for some 6 years, which is precisely why this TC's profile work must of necessity break compatibility with the ODF TC's work to produce profiles designed for interoperability of implementations. Setting up a different TC to advise the ODF TC is, in my opinion, organizational foolishness. Only the ODF TC has jurisdiction to negotiate the language of the ODF standard. Under OASIS Policy, the appropriate place for such advisory work is a subcommittee of the ODF TC. Likewise, if the goal is to produce conformity assessment procedures for the ODF standard, there are almost no remaining conformance requirements regarding the the elements and attributes that conform to the ODF standard that are not tested by validation against the schema after all foreign elements and attributes are removed. The *only* conformance requirements as to elements and attributes that remains without a conformance testing procedure is a short section of the ODF conformance section that specifies processing of foreign elemenents and attributes in a couple of situations. All other conformance testing in regard to elements and attributes would require one to assume the existence of conformance requirements in ODF that do not exist. Dave Pawson and I have reached consensus on this fact and I haver heard no disagreemnt. Dave is thus far willing to proceed with this proposed TC working only in only an advisory role on development of necessary conformity requirements in only an advisory role. I disagree with Dave on that specific point. As with the development of profiles, work on developing conformity assessment procedures for ODF depends on the ODF TC's development of conformity requirements and a subcommittee of that TC is the appropriate place under OASIS Policy for such advisory work to be done. If the goal is both interoperability and compatibility with the ODF standard, what is required is a policy change by ODF TC members in regard to the interoperability of ODF implementations, not a new TC. This is why, in my opinion, this formation meeting must achieve consensus on the goals of this TC with far more specificity. This TC either writes a new standard designed for interoperability using ODF as a rough guide that breaks compatibility with ODF or one joins the ODF TC to insist that the work be done on that TC. One may not have his cake and eat it too nor create a silk purse from a sow's ear. In my considered opinion, this formation meeting of necessity must decide between: [i] creating a new standard designed for interoperable implementations that breaks compatibility with the ODF standard; and [ii] leaving repair of the ODF standard up to the ODF TC. I perceive no middle ground. That is precisely why I proposed CDRF as the interoperability framework to be required in this TC's charter. If the goal is interoperable implementations, a break in compatibility with the existing ODF standard is unavoidable and CDRF is the only interoperability framework I know of that is both an open standard and suitable for working from the ODF standard to produce a new standard that breaks compatibility with a non-interoperable standard. If on the other hand, the goal is to maintain compatibility with the ODF standard whilst enabling the interoperability of implmentations, then CDRF is the only suitable interoperability framework for the ODF TC rather than this proposed TC to work its way out of the interop mess the ODF has created by ignoring interop issues in the specification for 6 years. . . . The need for this TC depends on this meetings' choice between those two options. Either the ODF TC cleans up its own interop mess or this TC creates a standard and conformity assessment procedures that are incompatible with the ODF standard. The choice could not be more stark. I am willing to work in either forum or under either work plan. I am also willing to consider any reasonable proposal to tie this proposed TC's hands to actually achieving an interoperable specification. However, consensus will not be reached on a charter that just trusts the folks who created the interop mess to do the right thing. I have a fully-informed basis for *not* trusting them to do the right thing. I will participate in no TC without an unmistakable message that the big vendor anti-ODF interop policies have turned a square corner. The message I require from the big vendors is specification of CDRF as the interop framework for the profile and conformity assessment work. I am willing to consider any alternative that provides equal or better specificiity in the charter in the commitment to actually achieving a set of profiles designed for interoperable implementations. My assent to the proposed charter turns on an unmistakeable good faith commitment in it by the big vendors to the actual achievement of interoperable implementations. I will not agree to trust them to do the right thing. Interop is not rocket science. The methodology is well understood and the only thing required to implement is agreement on the goal of interoperability. The only thing missing in the draft chater is a policy change on ODF interop by the big vendors. Absent strong evidence of that policy change in the proposed TC's charter, I will not agree to this TC's charter nor will I participate as a member of that TC if the Charter contains the slightest hint of trust of the big vendors to do the right thing. I have been down the road of trusting the big vendors to achieve interop for four decades and I do not trust them to achieve it in the few remaining years of my life. My support for the creation of a new TC requires that the TC charter display not a hint of trust of the big vendors to do the right thing about ODF interop. They have had six years to do the right thing about ODF interop. There is no informed basis for trusting them to do the right thing on the proposed TC. Interop requires agreement on the goal of enabling it. Every proposal I ave made aimed toward achieving interoperable implementations has been rejected or evaded by the big vendors. That provides sufficient proof to satisfy me that the anti-ODF interop policies of the big vendors have not changed in one whit. Either they endorse my proposals, come up with alternative proposals addressing the same interop breakpoiints in the ODF standard that are equivalent or better in quality, or this formation meeting is nothing but a fraud. So far, all relevant evidence supports the latter conclusion. The big ODF vendors talk the ODF interop talk; they have yet to begin the ODF interop walk and offer no work plan at this meeting to take that first step. There is an absence of consensus on enabling the interoperability of implementations of this proposed TC's profiles. I believe that further discussion of any other subject on this TC is but a waste of time if we cannot achieve consensus on that fundamental goal. If we achieve consensus on that goal, then all other discussion at this meeting have a guiding light. If there is no consensus on that fundamental goal, we all wasting our time directed toward any lawful activity. Interop in IT standards work is not a feature. It is the law and fundamental to competition in the market defined by a standard. Either the commitment to development of lawful profiles is there or it is not. See e.g., this statement by the European Committee for Interoperable Systems, the organization that is representing IBM and Sun's interests in the DG Competition investigation of Microsoft in regard to interoperability with Microsoft Office: " Interoperability is a cornerstone of the ICT industry. In today's networked ICT environments, devices do not function purely on their own, but must interact with other programs and devices. A device that cannot interoperate with the other products with which consumers expect it to interoperate is essentially worthless. It is interoperability that drives competition on the merits and innovation. The ability of different computer products to interoperate allows consumers to choose among them. Because consumers can choose among them, interoperable products must compete with one another, and it is this competition that has driven innovation in the software industry.". <http://www.ecis.eu/inter/index.html>. That is a fair summation of the law governing interoperability. But look at what ECIS says about ODF: "In an attempt to introduce widespread interoperability, competition, and consumer choice to this application area, major industry players have created a truly open standard for office productivity applications, called the Open Document Format (ODF). The standard was initially created through the OASIS standards organization, and in May 2006, ODF was formally recognized as an international standard by the International Standards Organisation (ISO). "However, Microsoft is seeking to displace the interoperability benefits of ODF with its new Vista and Microsoft Office products." <http://www.ecis.eu/inter/interoperability_and_open_standards.html>. The hypocrisy is plain between the ECIS summation of the law governing interoperability IBM and Sun assert against Microsoft and the ECIS portrayal of ODF as a standard designed for interoperability that already bestows interoperability is evident. We would not be having this meeting were ODF a standard designed fort interoperability that already bestwows such evidence. The sources of the ODF interoperability myth are well identified. They are IBM, Sun, and their camp followers like Pamela Jones and Andy Updegrove. Many people who Pam Jones aimed at this meeting to watch Microsoft -- which is is actually over on the ODF TC rather than here as it originally announced its intent -- are undoubtedly learning for the first time that ODF interoperability is a complete and utter myth. I negotiate here with the big vendors who disseminated the lie rather than dealing with the interoperability issues on the ODF TC. I negotiate with the big vendors who created the ODF interop mess and disseminated tjhe ODF interop myth for anti-competitiive ends. I negotiate with liars who are entitled to no trust to do the right thing in regard to ODF interop. I have been working on cleaning up the ODF interop mess for years, hampered by smear campaigns directed my way by IBM and its camp followers rather than addressing the merits of my public exposure of the ODF interop bugs.. I intend no disrespect, but people who trust the folks who created the ODF interop mess to clean it up are an impediment to making the ODF interop myth come true. I negotiate with people who have been avoiding any actual work on ODF interoperability for years and who cast stones at the character and reputation of those who make ODF interop bug reports rather than respondijng to the merits of ODF intero bug reports and proposals to repair those bugs I am not here to persuade anyone other than the folks who created the ODF interop mess. To achieve that persuasion, I raise only facts that they know themselves to be true and my characterizations of the applicable law that they are well equipped with lawyers to evaluate. I do attempt along the way to try to help people who are novices to the actual state of the ODF standard and the history of how it became an interop mess to become more clueful. My time available for the latter task is limited by the time necessary to achieve the persuasion I speak of. I recognize that some here are displeased that I provide no larger factual basis for my statements than I do. But I have no time for those not already highly familiar with the issues to slow down to prove everything I say. Please understand that IBM and Sun staffers know themselves what acts and omissions they have committed. I need only summarize the facts and law I rely on for those companies to determine whether my statements are susceptible to proof and are supported by the law. This is the process of negotiating a lawful agreement. Parties state what they want, provide the factual basis for their request, and the otehr side determines whether the request is compelled by law or a matter to be negotiated. The proposed TC's charter will either be a lawful agreement or not. Any remedy for its potential illegality lies outside the proposed TC after it is formed. The remedy for an illegal Charter lies in the court of public opinion, the courts, or the hands of competition regulatory officials. This post is an attempt to provide a clue for those not participating effectively in the negotiation. If one desires interoperability, one must advocate interoperability and for interoperability to be required by the Charter. Because I am far from having read every post, I can only say that among all the participants in this meeting, the only two people effectively advocating for interoperability that I am aware of are myself and Dave Pawson. All other posts I have read have been by people who either take the bystander role or oppose any requirement of interoperability being added to the charter and instead make specific proposals to weaken the Charter with discretion to introduce interoperability breakpoints in the proposed TC's work. The principle barrier to consensus regarding the charter is the issue of whether the goal of the proposed TC is interoperability. Best regards, Paul E. Merrell, J.D. (Marbux) -- Universal Interoperability Council <http:www.universal-interop-council.org>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]