Re: [oiic-formation-discuss] PROPOSAL -- Name change for proposed TC

[marbux <marbux@gmail.com>]

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>