[odf-discuss] A bit more detailed explanation of the AFNOR position

[marbux]

On 9/25/07, Lars Noodén <lars at umich.edu> wrote:
>
> marbux wrote:
> > ...
> > I distinguish between DIS 29500 (Ecma 376) and Microsoft's OOXML.
> > ...
>
> I don't.  They are, of course all different specs, but they share the
> common characteristics that they are not fully published, have licensing
> problems and are generally unimplementable by third parties.  Sharing
> these common characteristics is enough for me to lump them together.


I agree so far as you go, but the fact that there is no reference editor is
an important issue at ISO. What's a standard without implementations worth?


> ...
> > ODF in its present condition is generally a non-starter for eGovernment.
> It
> > has no interop framework whatsoever and no interop conformance
> > requiremements...
>
> Please describe this in a sentence or two.  I feel that I am being
> obtuse in that I am unable to see such shortcomings.


It would perhaps be most easily illustrated were you to compare the ODF
conformance section with that of the W3C's Compound Document by Reference
Framework's conformance section. <
http://develop.opendocumentfellowship.org/spec/?page=1#1.5> and <
http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>; e.g.:

> User Agent Conformance
> >
> >    1.
> >
> >    User agents must allow the child DOM to access the parent DOM.
> >    2.
> >
> >    User agents must allow the parent DOM to access any child DOM. The
> >    contentDocument attribute must represent the child document.
> >    3.
> >
> >    A conformant user agent of a superset profile specification must
> >    process subset profile content as if it were the superset profile content.
> >
> > That is only an excerpt; there is more to the section. But CDF has an
interop framework and conformance requirements that require non-lossy
round-tripping of documents between less and more featureful applications.
ODF does not. ODF has virtually no conformance requirements beyond
validation and allows implementations to destroy metadata created by other
implementations, discretion that Sun has fully exploited in StarOffice and
OOo to ensure that its apps remain the center of the ODF universe.

For the larger context of the component CDF specifications, see <
http://www.w3.org/2004/CDF/>. Profiles are not the only way to enable and
require interop; I raise CDF only as an example, one we are implementing.

> ... ODF is non-interoperable without lossiness, even among ODF
> > apps ...
>
> That appears from where I sit to be shortcoming in the applications not
> the format.  Is there something else that we should know about there?
> Random non-compliant tags, tagsets and metadata do not count.


Application-level interop hacks work for the developers who have agreed to
implement it. But it is an approach that has never worked in the office
productivity software market and is the worst choice for an open standard
that many apps use. E.U. eGovernment, for example, was quite clear that it
wants the interop at the file format level, not at the application level.

If you do not have an interop framework in the standard itself, what you
wind up with is what we have now; documents that cannot be round-tripped
among all ODF apps polluting the digital landscape and only OOo and
StarOffice able to handle whatever one ODF app might throw at another ODF
app.

Likewise, if there is no framework for interop with non-ODF apps like MS
Office, then only 1:1 feature mappings between MS Office and a given ODF app
can achieve lossless round-tripping of documents. And on the OOXML side of
the interop barrier, the lack of an interop framework and interop
conformance requirements for OOXML means only MS Office can handle whatever
one OOXML app might throw at another OOXML app.

Both ODF and OOXML are designed to cement in place the monopoly market share
of their respective market leaders by excluding non-lossy round trip interop
both with each other and among apps that support the respective standards.

But I disagree strongly on one thing you said.
Random non-compliant tags, tagsets and metadata *do* count when it comes to
non-lossy round-trip interop unless apps are required to preserve unknown
metadata within the context of an interoperability framework that spells out
what to do with unknown metadata. E.g., the WordPerfect interop framework
that wraps unrecognized metadata in <unknown> tags and rendering their
contents as text, then removes the <unknown> tags if the document is opened
in a later version that recognizes the metadata.

> ... let alone with MS Office.
>
> MS has todate never complied with an open format, specification or
> protocol.  MS will *NEVER* willingly give up an open format for MS
> Office, given that its current claims to profitability are based
> *entirely* on income from MS Office and MS Windows.  Any full-fidelity
> interoperability in the Office area, loosens vendor lock-in on Office,
> which in turn loosens the lock-in on the desktop.  Most nations agree
> that would be a step towards a free market in computing and this would
> be good.


Agreed. But no one is working on it. The big vendors talk the interop talk
but they don't walk the interop walk. And they proactively thwart interop.

Any interop with MS Office is going to have to come the same way
> accessibility software comes: via third parties and *in spite of* the
> best efforts of MS to stop it.


Agreed. But a nearly identical problem exists with ODF.

Our emphasis, and that of nations wishing to retain sovereignity, should
> be to focus on ODF apps.


Only if the ODF community suddenly develops some concern about what the
foxes in the ODF henhouse have been doing. ODF will never be a threat to
Microsoft's hegemony before it acquires an interop framework and interop
conformance requirements. And never before the interop barrier with MS
Office is cracked. We solved the Microsoft side of the problem but couldn't
solve the ODF side of the problem.

Clues: Sun Microsystems has the chairmanship of the ODF TC and a majority of
the votes there. Sun has been conspicuously absent from the battle over Ecma
376, voted at INCITS for Ecma 376 approval at ISO, is developing Ecma 376
native support for StarOffice/OOo with Novell and Microsoft, and both Novell
and Sun have agreements with Microsoft that provide patent protection for
StarOffice and Novell proprietary OOo, but no patent protection for free OOo
and pay patent royalties to Microsoft for their proprietary office suites.
Microsoft's recent announcement that it is leaning on enterprise users of
free OOo to pay royalties I think fills in the last large piece of the
puzzle. <
http://cnnmoney.printthis.clickability.com/pt/cpt?action=cpt&title=Microsoft+claims+software+like+Linux+violates+its+patents+-+May+28%2C+2007&expire=-1&urlID=22311448&fb=Y&url=http%3A%2F%2Fmoney.cnn.com%2Fmagazines%2Ffortune%2Ffortune_archive%2F2007%2F05%2F28%2F100033867%2Findex.htm&partnerID=2200>.


The set of agreements among Microsoft, Sun, and Novell and their individual
overt acts raise the appearance that the players deliberately decided: [i]
*not* to supply what is a clear market requirement of high fidelity
interoperability, [ii] to maintain competing and non-interoperable sets of
file formats; and [iii] to allocate the market for office suites, with
non-conspirators to be driven from the market with Microsoft's software
patent club.  See Palmer v. BRG of Georgia, Inc., 498 U.S. 46, 50 (1990)
(per curiam) ("[s]uch agreements are anticompetitive regardless of whether
the parties split a market within which both do business or whether they
merely reserve one market for one and another for the other"); NCAA v. Board
of Regents of Univ. of Okla., 468 U.S. 85, 103 (1984) (a finding that a
Sherman Act restraint of trade is unreasonable may be "based either (1) on
the nature or character of the contracts, or (2) on surrounding
circumstances giving rise to the inference or presumption that they were
intended to restrain trade and enhance prices"), quoting National Society of
Professional Engineers v. United States, 435 U.S. 679, 692 (1978).

And of course, a few other Linux distributors have joined since then,
shipping Novell OOo with their distributions after having reached agreement
with Microsoft.

Microsoft is not the only fox threatening the ODF henhouse.  There are a
couple of others already inside. Until ODF supporters wake up to that fact
and deal with it effectively by getting an interop framework and conformance
requirements into ODF, both for interop among ODF apps and for interop with
MS Office, Microsoft keeps its vendor lock on the crucial enterprise market.
The lessons of Massachusetts decision to approve OOXML, the successful
opposition to ODF mandate legislation in five U.S. states by state IT
officials, and the IDABC Open Document Exchange Formats 2007 Workshop
pronouncement that neither ODF nor DIS 29500 are acceptable formats because
of interop warts have simply not registered with ODF advocates, who remain
committed to a black hat/white hat evaluation of the issues.  But it is a
black hat/black hat situation instead.

Open and interoperable are not synonyms. They are quite distinct concepts.
ODF is open, but it is not a set of formats designed for interop. That
requires an interop framework and interop conformance requirements. ODF has
neither and supplying the interop framework and conformance requirements
only at the application level allows Sun to retain control over who is
entitled to non-lossy round-trip interoperability with its products.

ODF is not a Microsoft Office killer. It's not even a contender.

Best regards,

BUCK "MARBUX" MARTIN
  Director of Legal Affairs
  OpenDocument Foundation
  Contact:
<http://www.opendocumentfoundation.us/contact.htm>
-- Universal Interop Now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20070925/bccd0261/attachment-0001.htm