Proposed Use case -- Interoperability in vertical and horizontal ODF markets

[marbux <marbux@gmail.com>]

I propose that, amongst other tasks, the OIIC TC be tasked with
providing a set of profiles that clearly and unambiguously specify the
conformance requirements essential to solve the following use case.

1. DEFINITIONS and MARKET CONDITIONS:

Market A is that for ODF mobile device editors and all competitors in
that market each have unique implementations of ODF that support ODF
to varying degrees.

Market B is that for ODF web editors and all competitors in that
market each have unique implementations of ODF that support ODF to
varying degrees. The range of ODF features supported in this market is
broader than that in Market A.

Market C is that for ODF outliner editors and all competitors in that
market each have unique implementations of ODF that support ODF to
varying degrees. The range of ODF features supported in this market is
broader than that in Market B.

Market D is that for medium-capability ODF editors, e.g., KOffice, and
all competitors in that market each have unique implementations of ODF
that support ODF to varying degrees. The range of ODF features
supported in this market is broader than in Market C.

Market E is that for the most featureful ODF editors and and all
competitors in that market each have unique implementations of ODF
that support ODF to varying degrees. The range of ODF features
supported in this market is broader than in Markets D.

In each of Markets A through E, each competitor's ODF implementation
writes application-specific foreign elements and attributes in the
application's unique ODF namespace and is incapable of writing to
unextended ODF.

Market F is the ODF market for integration of ODF implementations with
service-oriented architectures at the enterprise level in business
processes that maintain, manage, and process silos of legacy data
stored in formats other than ODF. Integration of ODF implementations
in this market requires ultra-high fidelity interoperability for,
e.g., automated document assembly that (in oversimplified terms)  [i]
parses and extracts data from not only ODF formats but also a host of
other formats in the assembly of a given document; [ii]  in the
assembly of a given document converts/transforms all relevant
extracted data from multiple different formats in any combination to
an intermediary common data format; [iii] formats all assembled data
into a new document in the desired output format; and [iv] serializes
that output to the next application in the business process chain,
whether an editor or a viewer.

Automated data exchange actions in this market are commonly scripted
using business process data exchange languages such as BPEL.and using
integration "glue" frameworks such as Apache Cocoon.
<http://cocoon.apache.org/1363_1_1.html>.

2. USE CASE

This use case is posed by a single question based on the above
definitions and market conditions:

How may how may all conformant ODF implementations hold two-way
conversations with each other without data loss?


3. DISCUSSION

This use case parallels and supplements my CDRF proposal, posing the
problem solved by that proposal rather than its solution with a
particular interoperability framework specified in the charter. This
proposal responds to Rob Weir's request that a particular
interoperability framework not be specified. While I still prefer by
far that CDRF be specified in the charter, I extend this olive branch
to Rob and this meeting for discussion. I have attempted to tailor
this proposal to previous statements by IBM staff about the kind of
interoperability they want customers to have.

Rob roundly and correctly criticized OOXML because it did not specify
a solution to problems of the same time involving the interoperability
between less and more capable implementations of OOXML.
<http://www.robweir.com/blog/2007/03/compatibility-according-to-humpty.html>.
The same kinds of under-specification problems need be solved in ODF
for ODF to be much different from OOXML.

In response to a comment on that article by Microsoft's Doug Mahugh,
Rob debunked Mahugh's argument by stating in relevant part:

"Thanks, Doug. But none of that is really 100% compatibility with
legacy anything. That is really just saying that OOXML is compatible
with code that Microsoft is writing months after OOXML was
standardized by Ecma. But the qualities of the format were set the day
the standard was approved by Ecma. *The standard does not gain
capabilities by Microsoft writing code.* Microsoft applications may
gain capabilities, but the standard is what it is, and is as
compatible as it is going to get the day it was standardized. If OOXML
was really compatible with legacy binary formats then they would work
without requiring code changes or customer upgrades."

Rob's argument in that paragraph is the same as the distinction
between application-level interoperability and document level
interoperability on the Universal Interoperability Council web site.
<http://www.universal-interop-council.org/glossary/term/70>. The
conformity requirements essential to achieve interoperability must be
in the standard, not in the application. Because ODF has no
interoperability conformance requirements at all and is grossly
underspecified, ODF is susceptible to the same interoperability
criticisms Rob raised in regard to conversations between less and more
featureful implementations of OOXML and the specificity concerns Rob
raised in regard to OOXML.

Rob's argument there was an elaboration of the succinct and correct
analysis of the effects on competition and software users of a
standard that enables only intraoperability rather than
interoperability, published by Rob's superior, IBM Vice President for
Standards and Open Source Bob Sutor.
<http://www.sutor.com/newsite/blog-open/?p=1260>. That document and
Rob's later article adequately address the issues raised by my use
case and I incorporate by reference those documents into my discussion
here.

Although neither discuss the applicable law in their posts, as a
scholar of the law governing interoperability in standards work, I can
state with high certainty that Sutor's document was at least
thoroughly vetted by IBM counsel if not in fact drafted by counsel and
is very carefully crafted to be in complete harmony with competition
law in the European Union.

Sutor's document bears the footprints of the DG Competition decision
in regard to the ordered disclosure of the specifications for the
Windows and Windows Server communications protocols, sufficiently
specified in the disclosures to place competitors on an "equal
footing" in regard to round-trip interoperability with Microsoft's own
software in their interactions using those protocols.

That decision was upheld after Sutor's article by the Court of First
Instance in the case of Commission v. Microsoft. IBM and Sun
participated in that case both at the administrative and judicial
levels through their membership in the European Committee on
Interoperable Systems ("ECIS"), which was a party in that case,
represented by a highly skilled E.U. lawyer named Thomas Vanjes. That
case dealt with the issue of under-specification in technical
specifications that thwarted round-trip interoperability.

As to the remainder of both Sutor and Rob's documents dealing with the
interop barriers between less and more featureful implementations of
standards, the applicable law embodied in those documents is the
competition law concerning standards and the law governing agreements
and mergers in horizontal and vertical markets that is little
different in both the E.U. and the U.S. Both voluntary technical
standards and charters for the technical committees that produce them
are regarded by the law as agreements subject to the law governing
agreements among competitors in horizontal and vertical markets. In
the IT sector, this body of law has interoperability at its very
foundation.

Also because of my familiarity with the law in this area, I have very
high confidence that Sutor and Weir's documents reflect the law that
IBM and Sun through ECIS now assert against Microsoft In DG
Competition's new investigation of Microsoft commenced at the request
of ECIS. Among the issues reportedly raised by ECIS are the
under-specification of OOXML and OOML's failure to include the
specifications for the MS Office binary formats, the formats that
OOXML's compatibility with was the principal Microsoft justification
for an international standard duplicating the functionality of the ODF
formats.  Rob's article debunks that Microsoft position speaking
directly from the governing law but without identifying it.

While far from conclusive proof for those who are not familiar with
the applicable law, I offer supporting evidence that IBM and Sun are
asserting against Microsoft as legal grounds through ECIS precisely
what Sutor's document describes. One need only compare Sutor's article
with this page on the ECIS web site to see some very striking
similarities. <http://www.ecis.eu/inter/interoperability_v_intraoperability.html>.

The only thing different here is that we now discuss ODF rather than
OOXML. What is sauce for the goose is sauce for the gander. For those
of us helping to build a free information infrastructure for a
connected world, we have two show-stopper interoperability bugs to
repair at the office file formats level, OOXML and ODF. That one is
controlled by a monopoly and the other by an oligopoly has scant
relevance under the law and the technical work necessary to repair the
interop bugs still is necessary.

I submit Bob Sutor and Rob Weir's articles as my justification for
requiring in the proposed TC charter that my use case be solved by the
proposed OIIC TC. I point out that my CDRF proposal, as elaborated to
include a compatibility framework, was carefully designed to solve
that issue and that to my knowledge no one has yet offered an
equivalent proposal. (However I am now more than a week behind reading
post to this list.).

The world needs office document exchange formats. As Sutor lucidly
explains, standards that do not allow 2-way conversations between less
and more featureful apps are anti-competitive. If we are to have a
connected world, we must concern ourselves with the quality of the
connectivity. ODF and OOXML have remarkably similar interop bugs.
Those who wish ODF to survive and bring about healthy competition must
be concerned that we have something better to offer the world for
document exchange purposes than OOXML.

Rob Weir and Bob Sutor both already told us so. I submit my use case.

Best regards,

Paul E. Merrell, J.D. (Marbux)

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>