Re: [oiic-formation-discuss] Proposed Use case -- Interoperability in vertical and horizontal ODF markets

[marbux <marbux@gmail.com>]

On Thu, Jun 26, 2008 at 6:30 AM,  <robert_weir@us.ibm.com> wrote:

> I'm hoping the overall goal of the proposed TC, as stated in the eventual
> charter, will include something along the lines of "To improve
> interoperability among ODF implementations".

The TC formation notice says that development of ODF profiles are on
the table. Data format profiles in the context of a standards
development organization ("SDO") are standards and subject to every
technical, market, and legal requirement applicable to any other data
format standard including the legal requirement of responsiveness to
market requirements in horizontal and vertical markets and the
requirement that standards place all competitors on an equal footing
through specificity in the standard that requires no application-level
interop.

"To improve interoperability among ODF implementations" does not even
distinguish between lawful work on a standard and unlawful
application-level interop work not directed to lawful standard
development work in the context of a voluntary standards development
organization. What's the goal here, Rob, an ongoing Interop Camp for
developers to hack application-level interop or development of
standards?

Your company is litigating my use case with Microsoft in Europe in
regard to OOXML whilst ducking, bobbing, and weaving to avoid adhering
to the same law on both the ODF TC and on this proposed TC. One need
only read Sutor's article to understand why document exchange format
profiles for round-tripping between less and more featureful apps are
an absolute market requirement to level the competitive playing field
in the ODF app market.

 "To improve interoperability among ODF implementations" is both so
vague and so ambiguous that it is meaningless. It says nothing at all
about the *qualities* of the profile-related work or the market,
technical, and legal requirements those profiles will respond to. My
use case does.

I have your own article and Sutor's on the side of my use case
proposal. What do you have to show that you and Sutor were wrong in
what you wrote before?

"To improve interoperability among ODF implementations" says nothing
at all about working past the under-specification.issues in ODF and
blinks past the fact that ODF is an insufficient vocabulary for
profile-related  work because of gross under-specification.

> If so, we'll want to limit
> ourselves to the problems that actually exist among ODF implementations.
>  We'll have enough of those to worry about that I don't think we'll also
> have the leisure to tackle the problems that don't exist as well.

Feigning ignorance of the 150 or so app-specific extensions written by
OOo and the clones of its code base doesn't impress me, Rob. I've got
iron-clad proof you're aware of them.

Moreover, my use case deals with what the ODF standard currently
allows to happen, and is not limited to the extensions interop mess
that already exists. Your indifference to what the standard allows to
happen is telling, particularly given your prior statement to me on
the Fellowship list that you view ODF as a mere vocabulary for buyers
and sellers to express their profile requirements.

"I see a standard as providing a shared vocabulary for buyers and sellers
to express their requirements.  Some users, like IDABC will seek
applications that do not extend ODF.  ODF should provide a way of
expressing the technical side of that requirement.  Other users will have
stricter requirements.  Maybe archivists want to express the requirement
that all fonts be embedded and that no object embedding (OLE) is used, and
no macros or script is used.  So, something similar to PDF/A.  If so, ODF
should provide a conformance class to express that technical requirement.
And so on.  We can do these in the standard itself, or as separate
profiles.  But I don't think we can express a prohibition against
proprietary extensions as a technical requirement."

<http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/007307.html>

So far as I'm aware that is the first time you floated the idea of
doing profile work outside the ODF standard itself. But regardless,
ODF is an inadequate vocabulary for the expression of profiles and the
interop mess actually exists from ODF illegally granting conformant
status to app-defined extensions. I briefed the applicable law for you
in that thread, complete with quotations, citations, and links but you
remained stalwart in your defense of conformant status for such
extensions without addressing the law other than by attacking my
personal credibility in raising the legal issues. We also discussed
the problem of apps not retaining the ability to write to unextended
ISO/IEC:26300 and you made it plain that you were not only aware of
the problem but had no intent to do anything about it in your capacity
as co-chair of the ODF TC.

Now you turn 180 degrees and claim that you know of no apps that write
app-specific extensions to ODF without retaining the ability to write
to unextended ODF. Does the fact that  IBM slapped a different GUI
atop the OOo code base make it a different app in the context of Bob
Sutor's analysis of interop requirements in horizontal/vertical
software markets and the under-specification of standards claimed to
be "open?" I think the answer is unequivocally not.

My use case exposes the need for *document exchange* profiles and an
interop framework. Rather than tasking tasking the OIIC TC with
solving that riddle, you offer instead only a mere slogan, "[t]o
improve interoperability among ODF *implementations.*" Which ODF
implementations, Rob, and do you propose to do it through expounding
standards or through running an ongoing ODF Interop Camp on this TC
for developers doing application-level interoperability hacks without
bothering to get their hacks into a standard?  It's the difference
between lawful standards work and an antitrust conspiracy in restraint
of trade.

By omission, you seem to say that my use case exposes no interop
problems at all that actually exist and require solution.  See Sutor's
article and the contents of your own brain. You have plenty enough
knowledge to compare ODF to what Sutor said and respond within that
context to my use case and the need for the OIIC TC to solve those
issues.

> In any case, the ODF standard does speak to foreign elements and attributes,
> so an exhaustive test suite will of course include examples of this feature.

The profiles proposed to be developed by this TC have to speak to that
subject as well.

>  Since the ODF standard says that such content should be preserved,

As Dave points out, ODF section 1.5 says they *shall* be preserved,
not *should.* OOo 2.x is non-conformant because it eats all foreign
elements and attributes other than its own and paragraphs and text
spans. I haven't tested OOo 3.x or Lotus Symphony yet in that regard
but I'm not hopeful.

 we would
> check to see if that recommendation was observed and issue a "warning" if it
> was not.

Go ahead and issue it from the ODF TC to Sun now. There's no reason for delay.

>
> Personally, I'd be in favor of deprecating the use of foreign attributes and
> elements altogether, or at least limiting its use severely.  With ODF 1.2
> metadata we have a preferred framework for extending ODF, a framework that
> does not rely on foreign attributes and elements.

There is no ODF 1.2, only a draft so unstable that it is of no
practical use for the profile development work on this TC. E.g.,
Microsoft drew the line on supporting ODF 1.1 natively and joined the
ODF TC to work on ODF 1.2. If you have some kind of written assurance
from Microsoft that the RDF Metadata stays in ODF 1.2 rather than
bringing over the OOXML Custom Metadata to ODF 1.2, I'd love to see
it.

There is also the very significant barrier that Sun, IBM, et ilk,
gutted the Metadata SC's work at the last minute by removing all
metadata preservation requirements, replacing all occurrences of
"shall preserve" with "should preserve" throughout the SC's work. I'm
still waiting for a use case exposing the necessity of those changes
that could not be handled by a "shall preserve unless" grammatical
construct that lists the needed exceptions. Trashing RDF metadata by
conformant apps is fully authorized in the ODF 1.2 draft regardless of
the impacts on round-trip interop.

Bottom line: the foreign elements and attributes are the only present
means of round-tripping documents between an app that does not extend
the spec and those that do. Unless the ODF TC suddenly acquires any
intererest in round-trip interoperability and fixes the Metadata SC's
work, the RDF metadata work in ODF v. 1.2 is no standard-based interop
solution. Same-o, same-o: ODF underspecification. An app that trashes
RDF metadata required for interop purposes is a conformant ODF app
under the current draft ODF v. 1.2. You have to break compatibility
with ODF v. 1.2 to use the RDF metadata in profile work.

I had two alternative goals in my use case proposal: [i] getting a
conversation started with IBM about real world ODF interop issues; or
[ii] failing that, to establish yet further compelling evidence that
IBM talks the ODF interop talk but won't even talk about walking the
ODF interop walk. On this particular proposal, thank you for at least
giving me my second choice.

IBM's failure to address my use cases in terms responsive to its
previous interop talk in your article and in Bob Sutor's and in terms
of the same legal arguments IBM is making to DG Competition cinches
the antitrust noose around IBM's throat even tighter.

IBM has an unmistakable double standard, what quality of interop it
demands of Microsoft and what quality of interop it provides itself. I
predict that you and Bob are going to be very popular witnesses with
the antitrust sharks when they move in to kick off the ODF antitrust
litigation and begin picking the meat from IBM's bones. Just as a
general observation, collusive oligopolies usually fare no better in
antitrust litigation than abusive monopolies. I think IBM has very
serious liablity exposure in its double standard on OOXML and ODF
interop. There's big money for the Plaintiffs' Bar in that kind of
double standard and Microsoft's joining of the ODF oligopoly just adds
more meat to be picked from the corporate bones of the oligopoly.

E.g., here's what IBM and Sun told the world through ECIS about ODF at
the same time it was nailing Microsoft at DG Competition on the same
subject in regard to OOXML:

"The merits of ODF have already been established by its wide industry
adoption. As noted above, numerous PPA vendors have implemented
support for it in their products both on Windows and on other
operating systems. Such widespread adoption is only possible because
ODF is *fully disclosed and created to allow for document
interoperability by making it easy for various applications to
exchange documents with full fidelity, i.e., without any loss of data
or formatting of the document."*

European Commitee for Interoperable Systems (ECIS), Open Document
Formats as an Enabler of Interoperability: Comparison of the OASIS
OpenDocument format and Microsoft Office Open XML.(Undated but my copy
is file-stamped 07/2/07.). Formerly at
<http://www.ecis.eu/inter/documents/ECIS_ODF_OOXML_comparison.pdf>.

In other words, a bald-faced lie, the ODF interop myth. How does IBM
reconcile its claim through ECIS about the present state of ODF
specificity and quality of standard-enabled interop with the existence
of a TC formation notice that suggests making recommendations to the
ODF TC to improve interop among the subjects to be addressed by the
proposed TC?

And here's what IBM through ECIS still tells the world:

"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>.

You offer only unadulteratedt bullshit in response to my use case
proposal, Rob. Tell Sutor for me that I am weary beyond belief of him
yanking your strings and that it's past time for him to join this
meeting himself and do his own negotiating with me. I know that you
are not the IBM guy calling the shots here and I have no issues with
you at a personal level. Let's get the IBM ODF puppet master into this
meeting and start talking about IBM taking that first step on the ODF
interop walk. I've heard more than enough of the IBM ODF interop talk.
Time for action rather than bullshit.

Warmest personal regards,

Paul

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