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

[marbux <marbux@gmail.com>]

On Fri, Jun 27, 2008 at 5:09 AM,  <robert_weir@us.ibm.com> wrote:
>
> So we're all on the same page, note that ODF 1.1 section 1.5 says
> "Conforming applications that read and write documents may preserve foreign
> elements and attributes."

We are not on the same page. You simply continue to duck both the
merits of my use case and the violence done to all versions subsequent
to OASIS ODF 1.0 at JTC 1 when Patrick Durusau switched the
requirements keywords definitions specified in section 1.2 to ISO/IEC
Guidelines definitions from RFC 2119 definitions without doing a
solitary thing to fix the mischief he wrought.

Compare OASIS ODF 1.0,
<http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf>,
with ISO/IEC:26300 OpenDocument,
<http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html>
(near bottom of page; compare section 1.2 in both).

Here is what "may" meant throughout OASIS ODF 1.0:

"5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

<http://www.ietf.org/rfc/rfc2119.txt>.

Two *mandatory* MUST interoperability conformance requirements in
every occurrence of "may" in the spec, toggled off by Patrick Durusau
at JTC 1 after the national standardization body ("NB") ballot despite
OASIS ODF 1.0's unanimous adoption as was by the NBs. There never was
an NB ballot to adopt the altered version as the international
standard.

That presents a rather interesting legal situation because ISO/IEC is
a private standards development body, not a government standards body,
and only ISO/IEC rules and policies allow alteration of an
international standard after it is voted on by the NBs. But the
Agreement on Technical Barriers is superior, international law that
squarely places the obligation to adopt international standards and
technical regulations on the Member nations of that treaty, i.e., the
NBs that vote on its adoption.

So there is a very strong case --- even without looking at the
substance of the two versions --- that OASIS ODF 1.0 in the form it
was voted on by the NBs is the true international standard, not the
massacred version adopted by ISO/IEC as ISO/IEC:26300.

In other words, it is doubtful at best that the World Trade
Organization Appellate Body would hold that ISO/IEC:26300 is the true
international standard. That is even more likely because the massacred
version is not in fact a standard. ISO/IEC:26300 does not specify [i]
*all* characteristics [ii] of an identifiable product [iii] only in
mandatory "must" and "must not" terms. OASIS ODF 1.0 is not perfect,
but it comes exponentially  closer to those criteria than any
subsequent version.

But regardless of which is the official international standard, the
Durusau Massacre of ODF has not been repaired in any version and just
about everyone runs for cover or changes the subject every time I
raise the subject. Every interop conformance requirement in the spec
having to do with elements and attributes other than the requirement
of parking foreign elements and attributes in a unique application
namespace blinked out of existence through the magic of changing two
words to to four in section 1.2.

Of course your company and Sun would have to reprogram the OOo code
base to conform to the RFC 2119 definition, e.g., your apps would be
required to be able to write to unextended ODF to claim conformance
and they'd have to stop trashing foreign elements and attributes
indiscriminately amongst other issues discussed below. So I think I
have a pretty good understanding of where IBM is coming from when you
say you want to drop the foreign elements and attributes.

IBM doesn't want to share interop with anyone but folks who clone the
OOo code base. Even there, IBM distributes its own clones of the OOo
code base only in proprietary binary form, so IBM gets to extend its
own ODF apps even beyond the extensions OOo writes and hide the
functionality of its extensions without even source code for the FOSS
community to decode, yet still claim conformance.

IBM wants to keep the ODF "standard" the same blank check it's been
since the Durusau Massacre, the Massacre that handed IBM and Sun a
blank check to embrace and extend the standard without maintaining any
ability to write to unextended ODF.  E.g., run these parts from the
conformance section through the RFC 2119 filter that imposes two
mandatory interop conformance requirements on every occurrence of MAY
in the standard: (quoted from OASIS ODF 1.0 because it uses
capitalized letters where later versions use bold face):

"Conforming applications that read and write documents MAY preserve
foreign elements and attributes. In addition to this, conforming
applications should preserve meta information and the content of
styles. This means:

"• The various <style:*-properties> elements (see section 15) MAY have
arbitrary attributes attached and MAY have arbitrary element content.
All attributes attached to these elements and elements contained
within these elements SHOULD be preserved (see section 15.1.3);

"• elements contained within the <office:meta> element MAY have
arbitrary element content and SHOULD be preserved (see section 2.2.1).

"Foreign elements MAY have an office:process-content attribute
attached that has the value true or false. If the attribute's value is
true, or if the attribute does not exist, the element's content SHOULD
be processed by conforming applications. Otherwise conforming
applications SHOULD NOT process the element's content, but MAY only
preserve its content. If the element's content should be processed,
the document itself MUST be valid against the OpenDocument schema if
the unknown element is replaced with its content only."

Poof. There went the *mandatory* ODF document round-trip interop
framework so the apps that don't write extensions could still talk to
the ones that do but retain no ability to write to unextended ODF.
Bye-bye.

Poof. There went the *mandatory* requirement that the embracers and
extenders had to remain capable of writing to unextended ODF. Bye-bye.

Poof. There went the *mandatory* requirement throughout the spec that,
"[a]n implementation which does not include a particular option MUST
be prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality."
Bye-bye.

Poof. There went the *mandatory* requirement throughout the spec that
"an implementation which does include a particular option MUST be
prepared to interoperate with another implementation which does not
include the option (except, of course, for the feature the option
provides.)" Bye-bye.

Poof. The following unchanged sentence in the conformance section
acquired an entirely different meaning for *every* element and
attribute in the standard:

"There are no rules regarding the elements and attributes that
actually have to be supported by conforming applications, except that
applications should not use foreign elements and attributes for
features by the OpenDocument schema."

With the *mandatory* interoperability conformance requirements gone
from every optional feature, the sentence became a blank check to
destroy even conformant unextended metadata and still claim
conformance. Bye-bye.

Which brings us down to the lament of last September written by Thomas
Zander, the lead developer for the KDE KWord word processor and a
member of the ODF TC:

"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
lots of data.

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

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

Thus, the IBM-Sun oligopoly can claim conformance even as they trash
conformant, unextended ODF generated by other conformant apps to make
sure that ODF "competitive" playing field doesn't become level. They
rule the ODF market by market share and all versions of ODF after
OASIS ODF 1.0 became standards in name only, a de facto standards
disguised in the clothing of a de jure standard.

All because of the Durusau Massacre of ODF. Rob, you keep telling
people how ODF 1.2 is the answer to any substantive issue raised about
ODF interop.  It's irrelevant to what can be done with the
profile-related work on this TC because it is not yet stable.
Moreover, it is derivative of what I've got good grounds for believing
is not in fact the international standard. But I think you ascribe
trustworthiness to someone who has not earned that trust.
<http://blogs.sun.com/ontherecord/entry/patrick_durusau>:

"Noted XML standards expert Patrick Durusau will edit the 1.2 release
of the ISO/IEC Open Document Format (ODF), currently being developed
in the OASIS standards body. Durusau will be repeating the role he
played as editor of ODF 1.0, which was unanimously approved as an
International Standard in May 2006. He is also the chair of the
Metadata subcommittee in OASIS.

"Durusau's contract, sponsored by Sun Microsystems, allows him to
continue a role he had during the development of ODF v 1.0 and 1.1 in
OASIS, and in the submission of 1.0 to the ISO/IEC fast track
process."

Ah, yes. The same Patrick Durusau who helped IBM and Sun trash the RDF
metadata preservation requirements in ODF v. 1.2 by changing every
occurrence of "shall preserve" to "should preserve," to block the only
other possible way the FOSS da Vinci plug-ins could round-trip
documents in ODF formats with MS Office and OOo using ODF as the
intermediary, the same Patrick Durusau who has been kissing up to
Microsoft and was such a tremendous force in getting OOXML through JTC
1, trading on his reputation as the ODF Editor. E.g.,
<http://www.durusau.net/publications/publications.html>.

Take that "may" you're so pleased you found and stuff it in the RFC
definition of "may," then re-read the entire conformance section with
that set of eyes on. The conformance section means something entirely
different if the definition of "may" the standard was designed around
is used. Implementor discretion MUST be severely curtailed if anything
serious is going to get done about the ODF interop mess and my use
case exposes those problems.

The foreign element and attributes provisions, including their
metadata preservation requirements, were designed by Phil Boutros of
Stellent as a framework for round-tripping documents with legacy apps
and as a way for apps to round-trip extended ODF without data loss.

It is more than telling that IBM now wants to drop the ODF framework
for round-tripping documents completely rather than to even talk about
fixing the ODF interop mess exposed by my use case, the interop mess
in the standard created by the Durusau Massacre. You only supply
further proof of of IBM's actual anti-ODF interop agenda.

You can appeal to the ignorance of the mob all you want, but my use
case proposal is on the record of this meeting along with you own and
Sutor's prior statements on the subject of my use case.IBM and Sun
litigate my use case against Microsoft and OOXML in the E.U. and
falsely advertise ODF as designed for interoperability whilst
simultaneously ducking the same use case in regard to ODF.

You do no more than spatter the record of my proposal with your mental
feces without addressing my proposal's merits. You merely sink
yourself, Sutor, and IBM deeper into the antitrust sharks' jaws every
time you reply with more distractions. It won't be the folks here who
determine liability.

Past time for that first step on the IBM interop walk. Way past time.

Warmest personal regards,


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

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