Re: [oiic-formation-discuss] Caution and Disclaimer on Interoperability

[jose lorenzo <hozelda@yahoo.com>]

I took a quick look at ODF, and it is weak in terms of
preventing abuse. It's great for those that want to
interoperate, but it's weak in keeping those that want
to break interop in line.

For example, it's generally difficult to put into a
set of consistent rules, in a clear fashion while
allowing for growth and new features/semantics, rules
to the effect: "all paragraphs [whatever that means]
must be specified using X or Y XML."

ODF doesn't appear to be doing that (maybe if I read
the whole document I would find cases where this is
happening). Instead the much easier approach is taken:
"if you use this XML then the following semantics
apply [perhaps here too leaving room for growth, ie,
leaving some loopholes for abusers]."

Thus if I want to create a simple paragraph on page 1
of a simple text document, I know what XML I can use
IF I want to be guided by ODF, ..BUT I also have the
freedom to invent a secret recipe that in the end
basically just puts down a paragraph (maybe with
extended semantics) but in a way no one besides me
will understand.

This is conformant behavior according to ODFv1.1 [As
stated at the top of this comment, it's generally
difficult and impractical to attempt to stop abuse by
trying to be comprehensive or by trying to start with
imprecise concepts and attempting to lead back to
mandatory (precise) XML].

Thus it's easy for a vendor having monopoly control or
very large market share to take advantage of
extensions, the more the merrier. They would likely
not violate ODF as long as they avoid the ODF
restricted XML (ie, avoid the ODF-defined namespaces).

Anyway, to quote the very beginning of ODF v1.1 [
http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html
], which quickly and clearly lays out the HUGE
loophole:

>> Documents that conform to the OpenDocument
specification *may contain elements and attributes not
specified within the OpenDocument schema*. Such
elements and attributes must not be part of a
namespace that is defined within this specification
and are called foreign elements and attributes.

No more than that is needed as evidence (unless there
are exceptions or if this were to fall within a
specific narrow scope.. which I don't think is the
case), but I'll quote some more. To re-emphasize this
aspect, ODF continues at the beginning of chapter 2:

>> Conforming applications either shall read documents
that are valid against the OpenDocument schema if all
foreign elements and attributes are removed before
validation takes place, or shall write documents that
are valid against the OpenDocument schema if all
foreign elements and attributes are removed before
validation takes place.

So you can have a document that has the outside
required shell of ODF and then basically be nothing
but OOXML (using a proper namespace), and it would be
legal ODF. Worse (is that possible?), you could place
.doc binary files in there and it would be legal ODF.

So my next question is why did it take the office
suite monopoly vendor that long to get on board? They
are getting a free pass.

OK, I admit, I did not write the prior email with this
info in mind (it's been a long time since I looked at
the openoffice/staroffice specs (prior to ODF)). What
we have is not just theory, but that the actual ODF
spec, as it stands today, leaves all the loophole that
any vendor looking for lock-in would ever need to
comfortably put in all their proprietary bits while
remaining compliant. [Anyone following along but still
not believing can read it for themselves at the ODF
link above.]

I also suspect that not even foreign element tags
would be needed to put things like "=SUM(..)" within
spreadsheet cells without breaking conformancy; thus,
the same flexibility that allows COOPERATING vendors
to add extensions like the above to spreadsheets,
means non-cooperating vendors have all the loophole
they need to break interoperability and then some.

In short...

You said:
>> So I wouldn't underestimate the interest that
vendors have in seeing ODF interoperability improve.

To which I'll reply:
And I wouldn't underestimate the interest at least one
vendor has in seeing ODF interoperability fail
miserably when it comes to interoperating with the
existing monopoly product.

Thus anyone working to improve ODF should recognize
that it's unlikely that any definition of conformancy
will ever really prevent any vendor from being both
compliant and at the same time being completely (for
practical effects) un-interoperable.

Instead, the aspirations would be to write a standard
that will help minimize the un-interoperable cases for
those that really truly want to interoperate.

To repeat more clearly, don't expect to succeed in
withholding the "conformancy" label from any monopoly
vendors wanting to embrace and extend with intent to
extinguish. Instead, look towards this work with OASIS
as a way to make things easier on groups that really
do want to standardize and interoperate.

Let me also make a suggestion here. We can define a
family of metrics that describe thing like how many
bytes of the document are within foreign elements vs.
how many are within standard elements but not within
any foreign element. But even here, I think that
binary blobs are possible so that they fall only
within standard elements. And since a .doc may not
have any well-defined XML elements inside, it may thus
appear 100% within standard elements. ..Oh, well. I
tried.

--- robert_weir@us.ibm.com wrote:

> jose lorenzo <hozelda@yahoo.com> wrote on 06/11/2008
> 06:32:09 PM:
> 
> > I just joined today, so please excuse if I am
> > repeating material or am a bit off topic.
> > 
> > "Interoperability" and similar terms should be
> defined
> > precisely and conspicuously.
> > 
> > In particular, I think a note should be made that
> > interoperability does NOT mean that what an office
> > suite user visually sees and then saves using one
> > "interoperable" or "conformant" application can be
> > rendered faithfully on another such conformant
> > application.
> > 
> 
> Hi Jose,
> 
> Welcome to the discussion list! 
> 

Thanks. Nice to have the opportunity to share
thoughts. I hope I don't make your job too difficult.

> I'd say that one definition of interoperability is
> that a document appears 
> the same visually on two different conformant ODF
> implementations.  But 
> this is not the only definition of interoperability.
> 

I only mentioned the visual aspects (as one example)
to quickly convey that some types of tests are never
likely to become automated and unambiguous, at least
not in the near future. [Contrast with the relatively
easy to automate tests which test adherence to W3C
Schemas.]