[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] PROPOSAL -- Name change for proposed TC
On Thu, Jun 19, 2008 at 1:31 AM, Dave Pawson <dave.pawson@gmail.com> wrote: > > I also find it bad practice to be so close to an EU proposal. > Not a problem for me, Dave. I've got the proof nailed that this proposed TC is smoke and mirrors to distract from the real negotiation of ODF interop with Microsoft.. > Alternative proposal. > > > "ODF Interoperability and Conformance Technical Committee" How about: "ODF Interop Smoke and Mirrors Technical Committee" :-) > Telling Sun/IBM/FOSS guys how to do their job is > stupid and a waste of time. I agree. But I see some value in alerting folks who fell for the ODF Interop bees wax. On Sun and IBM, I've had conclusive proof of their real position on ODF interop for a long, long, time. That position is written all over the ODF TC archives and in the spec itself. This was just to give them an opportunity to show a sign that policies have changed. Someday the ODF interop mess will get straightened out or ODF just fades into the Sunset. (couldn't resist the double entrendre). The winner of the office file format war will be the first open standard that enables high fidelity round trip interop between less and more featureful implementations. Standards stuck on the desktop aren't even in the running and it's plain now that IBM will continue to block the kind of ODF interop the market requires. Six years now since the ODF TC was formed and I'm still waiting to see the first step on the ODF interop walk. The only ODF interop steps I've seen have been steps away from ODF interop. I got to see it up close and personal when I was working on the ODF TC. I have no concept how Gary Edwards was able to sit through every TC meeting and phone conference between the TC's formation and when we both decided last year that the only way to salvage ODF was to go public with the issues. E.g., <http://www.linuxworld.com/news/2007/072307-opendocuments-grounded.html>. (Our article detailing the reasons ODF failed in Massachusetts). Didn't work because of the smear campaign counter-attack by IBM and its crew and because of all B.S. they disseminated about ODF that conflated "open" with "interoperable." Plausible to folks who didn't understand the technology or the standard, but only an appeal to ignorance. The same kind of crap Microsoft gets burned at the stake for. I'm going to stick around on this list and continue offering constructive proposals. History teaches that they'll get shot down. But I haven't given up on interop. I've been cussing interop breakpoints since the punched paper tape days and I'll probably still be cussing them on the day I die. The big vendors have no solution to the ODF interop problem. They *are* the ODF interop problem. > Give them something to test compliance with a workable > standard (Conformance testing) and they might react positively > (sidestepping Pauls assertions). :-) There's stil the problem that when it comes to elements attributes there's nothing left to test for conformance that isn't already handled by validation against the schema after all foreign elements and attributes are removed. Well, there is that little bit of section 1.5 that has a couple of mandatory requirements for handling foreign elements and attributes that aren't tested by validation against the schema after the removal of all foreign elements and attributes. Like I said, if you want to test for conformance of anything else, you have to assume the existence of conformance requirements that don't exist just to get to the normative portions. ODF stopped being a standard when Patrick Durusau, acting as the JTC 1 Editor for ISO/IEC:26300 toggled the RFC 2119 requirements keyword definitions to ISO/IEC Guidlines definitions. I'm serious; the only way I ever got to any conformance requirements on the normative portions dealing with elements and attributes was to assume the existence of the RFC 2119 definition of "may" rather than the ISO/IEC Guideline definition. Without that definition all elements and attributes in the standard can be replaced with foreign elements and attributes and the document still conforms. So you have to merely assume the existence of conformance requirements to get to the normative portions dealing with elements and attributes. They were read out of existence as to conformity with the swtich in definitions. . But that brings to mind that I had a few more thoughts about which is the definitive version of ODF. As I explained before, that depends on legal context. But the new thought in that regard is that if one were to ignore the law and approach the question purely from a practical standpoint, the definitive version should be OASIS ODF 1.0. ODF was developed using the RFC 2119 definitions. OASIS ODF 1.0 is the only version of ODF not obliterated by the switch to ISO/IEC Guidelines definitiions.The only way you can make any sense out of the standard is to use the version that uses the RFC 2119 definitions. All other versions never got the repair required to clean up the mess created by the switch in the definition of "may." So as a practical matter, I see two alternatives here. One is to stick with the ISO/IEC definitions and vet the entire standard for every occurrence of "may" and rewrite all those sections to repair the damage. The other is to switch back to RFC 2119 definitions in ODF 1.2 and assess only the occurences of "may" added since the OASIS 1.0 version. A diff could identify them. No, wait. Patrick Durusau is rewriting the spec from stem to stern and reorganizing it. A simple diff won't work unless you start from the last draft version that wasn't reorganized. . IBM doesn't want to deal with the problem either way, which in and of itself is telling. Rob's excuse that ISO/IEC definitions are mandatory for JTC 1 specs doesn't hold water. They are not mandatory for XML specs and even if they were, no one seems to be all that concerned with obeying the Directives at JTC 1. If there was such concern,, neither ODF nor OOXML would have made it past the Directives requirement that international standards "clearly and unambiguously specify the conformity requirements essential to achieve the interoperability." That's a requirement that requires the consent of the Secretaries-General of ISO and IEC to ignore, but no one bothered to ask for it. Somehow, I suspect folks would rather have interop than worry about which requirements keyword definitions are used. > Interop responses would be a recommendation back to the main TC. > Conformance would be a test specification. > Profiles (the exchange profile is the most interesting one yet Paul) would > be a bonus. I can't take the credit. We all stand on others' shoulders here. If you combine the E.U.'s insistence on profiles for document exchange and CDRF, it's clear that I'm riding on other's coat tails. CDRF is a testment to what gifted and thorough experts can accomplish when they unite on the goal of actually achieving interop. By making the standard open as well as application and format neutral, they gave an incredible gift to the world. The barrier I see on what you propose is that the ODF TC would just ignore it unless the recommendation were accompanied by massive pressure on them to act on it. Maybe we could take the issue to the E.U. and see if they're willing to twist the necessary arms? I suspect that the E.U. folk would not be pleased to see the way IBM ran from my name change proposal and its justification. But let's keep brainstorming. I think it's going to require a combination of the technical, the legal, and the political to get this interop knot untied. There are lots of creative minds here if folks start talking about how to achieve interop rather than just mouthing the words and filling out the charter before the market requirements to be fulfilled by the TC are even identified. I say that actually achieving interop is the fundamental market requirement, but folks are objecting like crazy to actually tying the TC's hands to fulfillment of that goal. I really appreciate your candor, Dave. You are a delight to work with. Best 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]