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

[marbux <marbux@gmail.com>]

On Sat, Jun 28, 2008 at 11:24 AM, Thomas Zander <zander@kde.org> wrote:
> On Saturday 28. June 2008 19:52:53 marbux wrote:
> Thats not true, that usecase is only possible by accident. Instead that part
> was designed for allowing an implementation to have a feature that is not
> (yet) in ODF.


Wrong according to Gary Edwards. He was on the TC and very active when
the foreign elements and attributes parts of the conformance section
were developed. Neither you nor Rob were yet members.

The way Gary tells it over and over is that the foreign elements and
attributes chunks of the conformance section are a compatibility
framework developed by interop wizard Phil Boutros of Stellent, which
markets conversion filters for over 400 file formats and a host of
apps built atop their conversion filters.

The foreign elements and attributes parts of the conformance section
were specifically designed for round-tripping documents between apps
that support ODF and apps that don't via conversions. The *primary*
barrier the Phase 1 developers of ODF were looking at was as follows:

If there were conversion filters in ODF apps for converting between MS
Office formats and the ODF implementations were writing different
markup to store MS Office metadata they didn't support, the ODF
implementations would have issues in sharing documents amongst either
other that were converted from Microsoft formats before returning them
to MS Office formats.

If ODF was going to break the monopoly through the combined efforts of
its competitors, the ODF implementations had to have a standard way of
embracing the Microsoft formats. Otherwise, every major ODF
implementation would be an island in its conversations with MS Office.
Because they were dealing with a monopoly, they could achieve no
networking effects in their combined efforts to break the monopoly
absent a common compatibility framework for conversations with MS
Office.

 The compatibility framework was also intended to allow legacy apps to
support the ODF standard and still round-trip documents between their
legacy in-memory binary representations (IMBR) of documents and ODF
formats without data loss. E.g., this is where the ODF document
settings extensions interop mess originated from, legacy apps like OOo
that had to store document settings in ODF for backward compatibility
with the existing code base reasons. Foreign elements and attributes
were the only means provided by ODF.

There were also feature mismatches between the apps of the major
developers who worked on Phase 1 of ODF 1.0 development like Corel and
Sun. To round trip documents with each other without data loss, they
needed a standardized way of creating the extensions they needed and
processing each other's extensions to preserve metadata needed for the
return trip.  That's what the foreign elements and attributes
compatibility framework provided.

The foreign elements and attributes chunks of the conformance section
were also designed as a compatibility framework for the embracers and
extenders of ODF to have a standardized way of processing extensions
and preserving the extension metadata required for the round trip. So
you got this part right, but you missed that it was not originally a
blank check for folks to create extensions without worrying about the
processing of the extensions by other apps.

Go back and read the conformance section using the RFC 2119 definition
of "may" that was in OASIS ODF 1.0.
<http://www.ietf.org/rfc/rfc2119.txt>. I you do and spend some time
thinking about it, you'll see a compatibility framework for
round-tripping documents, not a blank check to create extensions
without worrying how other apps will process them.

Maybe then you will finally begin to acquire a glimmer of the Durusau
Massacre of ODF at JTC 1 when he switched the standard from RFC 2119
requirement keyword definitions to ISO/IEC Guidelines Part 2 Annex H
definitions, *after the OASIS ODF 1.0 standard had been unanimously
adopted by the NBs.*  That was way, way more than an editorial
correction.

You will also notice in the conformance section that reading it with
the modal definition of "may" the standard was designed around that
imposes two *mandatory* interoperability requirements on every
occurrence of "may" in the standard, OOo would be prohibited from
eating non-extended ODF elements and attributes indiscriminately. So
if the confornance section was working as designed and conformantly
implemented in OOo, you wouldn't have to write things like this:

"One thing I have always dreamed to be possible is that when I write a
doc in KOffice I can then open it in OOo to use that one feature
that's useful to me and then save it and continue in KOffice without
loosing [sic] lots of data.

"Its still a dream, of course. Most features are lost on opening and
saving it in OOo, but its [sic] a nice goal [.]"

<http://www.oasis-open.org/archives/odf-adoption/200709/msg00032.html>.

And of course if the RFC 2119 definition of "may" was still on the
clause that says that conformant apps "may" write foreign elements and
attributes in their own namespaces, every conformant editor would be
required to be able to write to unextended ODF.

But just about all the the foreign element and attribute rules about
preservation and processing of them went out the window when RFC 2119
went away. And the closing paragraph of the conformance section that
says there are no rules about what elements and attributes must be
supported got transformed into an authorization to trash other
conforming apps' unextended ODF.

> The important distinction here is that other ODF implementations can read 99%
> of the doc.

Can but don't have to. They also can but don't have to preserve
unextended conformant elements and attributes See your quote above. I
think your own reported experience with OWriter and KWord teaches that
your 99 percent figure is more than a tad bit off. "*Most* features
are lost on opening and saving it in OOo." Those are your own words,
Thomas, and "most" means more than half.

So, marbux, your disagreement is based on a misunderstanding.
> ODF is not meant to be used for a document created by an application that
> does not support ODF.

Wrong. See above.


> Any support for that usecase is purely coincidental and not a supported
> usecase of ODF.  It certainly looks like its off topic for the proposed TC.

Supposedly, this proposed TC is about ODF interop. And Rob has already
ruled that "interop with other formats" is on-topic.
<http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00357.html>.

> To OASIS; is there some code-of-conduct that people have to abide by on the
> OASIS mailinglists?

I asked Rob to create some but he refused.

I see the mails from Paul have a returning theme, they
> put into bad light respected members of our community. The continued
> bad-wording of those respected people makes me weary of replying and of
> sharing my experiences here.

But no issues with the folks running around the list calling me names
like Andy Updegrove and Pam Jones, eh?

Coming from one of the guys on the TC who gang-brutalized Florian
Reuter and who personally sent me emails trying to convince me that
Florian was a "code monkey," you don't have a lot of room to complain,
Thomas. Those "respected members of our community" you refer to,
including yourself, are the ones who made ODF such a holy interop
mess. You yourself sold compatibility with ODF 1.0 and 1.1 and
roud-trippability with MS Office down the river in ODF 1.2 so you
wouldn't have to write a conversion filter for the way you implemented
ODF in the earlier versions.

Where were you the whole time IBM and Sun have been telling the world
that ODF already was interoperable because it was open. Hiding on the
ODF TC and the ODF Adoption TC begging Sun and IBM for more crumbs?

Nearly as I can tell, you chose long ago to be part of the ODF interop
problem rather than its solution and you've certainly acted as though
you have been indifferent to your users' interop needs.

> ps. for people that don't know me, I'm a core-developer of KWord, the word
> processor of KOffice. The often used quote to describe KOffice is that its
> the second main ODF implementation.

Second main non-interoperable ODF implementation and one of the guys
who helped stop the only folks who were actually pushing the interop
issue on the TC. You've got a record to advertise, Thomas, if you ever
want to get a paying job at IBM or Sun. But I doubt your users would
be so thrilled if they comprehended what you have done and tolerated.

Best regards,

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

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