Re: [oiic-formation-discuss] The importance to users of documents looking the same

[marbux <marbux@gmail.com>]

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>