[odf-discuss] A story of TIFF

[marbux]

On 2/3/07, Daniel Carrera <daniel.carrera at zmsl.com> wrote:
> On Sat, 2007-02-03 at 04:06 -0800, marbux wrote:
> > I think you've missed something somewhere along the line. 65 % interop
> > with OOo was what was achieved by the August version of da Vinci that
> > was based on ODF 1.0 with its optional foreign metadata tags. My
> > understanding is that the current version using the proposed ODF 1.2
> > changes already achieves near-perfect interop in both directions
>
> How is that possible considering that ODF 1.2 doesn't exist yet, much
> less it's implemented in OOo. Are we using the same definition of
> "interoperability"?

I was clear in what I said. You're arguing with an implicit
mischaracterization of what I said, and that's a straw horse argument.
See <http://en.wikipedia.org/wiki/Straw_Man>. Your argument is
therefore a fallacy and requires no further response. If you want to
discuss things with me, please address what I did say rather than
misrepresentations of my words. We'll arrive at agreement much sooner.

My definition is essentially that if you save a file
> in application A you can open it in application B with only minimal
> differences (the definition of minimal is context dependent). So, in
> response to ODF 1.2 and interoperability: (1) I am not aware of any
> planned feature in ODF 1.2 that will remove the binary blobs that the
> Foundation plugin currently uses.

My definition would be no differences whatsoever. Anything less is not
interoperability, it's limited compatibility. In my mind, there is no
such thing as partial interoperability. Interoperability implies full
fidelity, but full fidelity does not imply interoperability. I often
emphasize my understanding of "interoperability" by preceding that
word's usage with the adjective "full."

Alex understood what I was saying about the proposed ODF 1.2
extensions  for resolving the issues with the remaining uncracked
binary blobs and any new ones Microsoft adds. He said in relevant
part: "Exporting proprietary Office binary blobs as "dark matter" and
flagging it for OOo to attempt to understand: it's an interesting
approach."  You can understand it too. You might talk things over with
Alex if you don't understand after rereading what I said.

(2) Since OOo doesn't support ODF 1.2
> (because it doesn't exist), it seems logically impossible to say that
> the current version of the plugin achieves near-perfect interop in both
> directions.

Nope. I was clear in saying that the plugin depends on features not
presently supported in ODF. You responded with a straw man argument,
premised on a mischaracterization of what I said. Your argument is
fallacious and requires no further response.

> > >That's the problem: setting up proprietary ODF formats
> > > which only certain apps have any hope of reading. It's detrimental to ODF.
> >
> > I won't say much here because your quoted sentences were apparently
> > based on a misimpression of what the current da Vinci build does.
>
> Are you saying that the da Vinci plugin does *not* insert unknown binary
> blogs ("dark objects") into ODF files which cannot be understood by
> other applications?
>

Darn few. Most have been cracked. With five proposed extensions to ODF
in v.1.2, the remainder can be cracked over time, at least well enough
to break the Microsoft Office monopoly and force Microsoft to natively
support conformant ODF.

> > [snip] I think you have to balance the drawbacks against the benefits.
>
> I'm glad that you recognize the existence of drawbacks. Almost every
> option in life has both drawbacks and benefits and decisions should
> almost always be a balancing act between the two.
>
> > The benefits to users are tremendous. They don't have to use MS Office
> > just to maintain interop with it;
>
> Any plugin that can successfully convert ODF into EOXML or an internal
> MS Office representation will achieve this goal. This is not a case in
> favour of binary extensions.
>

Wrong, I think, at least as you've chacterized your theory regarding
ODF <> EOOXML conversions in your other post. Like ODF, EOOXML has
tags for wrapping dark objects too and those dark objects apparently
are dependent on Office and/or Windows. Any theory that doesn't
address the need to crack the dark objects isn't aimed at full
interop.

To boot, any interop approach that depends on ODF <> EOOXML
conversions builds Microsoft's case at ISO for standardization of Ecma
376, which would be no small setback for ODF adoption. There is a
method to Sun's madness in its plans to only support EOOXML import in
OOo. Novell is taking something more like your approach using the
Clever Age code base, but I don't hold a lot of hope there. It's
perhaps telling that Florian Reuter is the guy doing the work for
Novell and is still the Foundation's CTO and going forward with the da
Vinci plugin and the ODF Infoset API. If the Clever Age approach was
actually equal to or better than the Foundation approach, I doubt that
any of the Foundation folk including Florian would still be working on
it.

Moreover, Microsoft is already taking steps to break what little
MOOXML <> ODF compatibility exists only imperfectly provided via
EOOXML. The new Excel 2007 binary infoset format is strong testimony
that the in-memory binary representations of the Office file formats
and their dumps to binary files are the most stable interop targets
for development. There also is no Microsoft commitment whatsoever to
confining itself to the EOOXML specification in Office and every
reason to expect that they will not.

For starters, the Ecma 376 TC's work plan has changed from ensuring
compatibility with the legacy binary formats to ensuring compatibility
with MOOXML. That is tantamount to an announcement that EOOXML is only
a subset of MOOXML. Second, the allowance for wrapping dark objects in
EOOXML tags testifies that MOOXML is not entirely XML but also
includes proprietary binary blobs.

Indeed, the packaging of the new Excel proprietary binary Infoset
format in MOOXML Zip files is pretty compelling testimony that the
approach you suggest was already largely obsolete before the public
release of Office 2007. Want to take any bets on whether the backports
of the Office 2007 MOOXML native file support to earlier versions of
Office also support the proprietary Excel binary Infoset format?

Do you doubt that Microsoft would do the same for Word and PowerPoint
if someone actually achieved EOOXML <> ODF full fidelity for those
apps?

Finally, when we were working the EOOXML Issues Grokdoc document, I
don't recall any objections from you on the document making a big
point of EOOXML offering only one-way full compatibility, inbound to
Microsoft Office. Yet you now suggest folks should fugettabout the
Foundation's plugin and build OOo-MS Office interop on top of EOOXML?
Give me a break.

A blob is a blob is a blob, whether wrapped with MOOXML tags or ODF
tags. But targeting the in-memory binary representations and their
dumps to file is in my mind the only practical approach to the
problem. I still haven't heard any reason to believe otherwise.

> > If ODF were a set of formats designed only for a single office suite
> > and nothing else, and flawless interop with MS Office was not a market
> > requirement, then I'd say, sure, keep all the foreign metadata out.
>
> You seem to think that those binary blobs will achieve interop. Or maybe
> you have a different definition of interop. But interop as I defined it
> above, is not fixed by adding binary dark objects. I'm not aware of
> anyone who proposes otherwise.

You do in your proposed solution, implicitly, as discussed above. The
Foundation folk are the only people I know of who even have a goal of
full interop that addresses the problem of the dark objects. You have
overlooked that your own proposed solution involves dark objects too.

What the unknown binary blobs accomplish,
> provided that applications don't drop them (as expected in ODF 1.2), is
> round-tripping: Say I have MS Office, and you have OOo. I send you a
> file. It looks like crap on your system, but you make an edit anyways
> and send it back. I would still be able to see all the items that you
> could not see. In this situation we do not have interoperability. What
> we have is MS Office round-tripping.
>

Again, you've overlooked that the Foundation has proposed a solution
to the blob problem. You have also overlooked that your proposed
solution does not address a similar dark object problem. The
Foundation has blobs in their proposed solution. The difference is
that they have proposed a solution to the dark objects problem and you
have not. That is necessary to move past full fidelity to full
interop. They address the problem through the ODF foreign metadata
tags, a proposed MS Office ODF interop subset, and five proposed ODF
extensions that allow adequate description of the blobs" content as
more is learned about them. Meanwhile, their approach already has
achieved near-perfect fidelity. Do you have a Band-Aid for your
suggested solution that addresses the dark objects problem and the
problem of Word's primitive page layout engine that defies mapping all
of ODF to Word? Do believe Clever Age has solved that problem? I'm
willing to listen to your reasons if you do.

Enabling interop with MS Office has been an agreed priority goal for
ODF design from the first meeting of the original "OpenOffice XML" TC
forward. That goal acknowledges the reality that Microsoft wields its
file formats as anti-competitive weapons and has the lion's share of
the market in no small part due to that tactic. Full fidelity with
Microsoft's formats is a market requirement for ODF and full interop
is as well. Phil Boutros of Stellent, who probably knows more about
file conversion issues than anyone else on the planet, pointed the way
with the ODF section 1.5 conformance section. Applied research into
the issue has shown that refinements are needed in ODF to achieve the
TC's MS Office fidelity and interop goals.

Full fidelity allows shops to migrate from MS Office to ODF apps and
goes a long way toward allowing migration to non-Windows platforms as
well, in manageable phases instead of requiring a massive rip and
replace overnight switch that would bring most enterprise-level
operations to a standstill for weeks if not months. Full fidelity also
allows governments and corporations to migrate to ODF while still
complying with laws that require that they preserve all information in
their documents.  So far, the only successful migration of a fairly
large shop to ODF I'm aware of was the city of Munich, and their cost
per seat of doing so was around $3,700. The city of Bristol recently
changed its mind because of the same stone wall. Rip and replace is
not a viable solution in shops that are dependent on Microsoft-bound
automated business processes.

The Foundation jumped into the breach when Massachusetts hit the stone
wall of Microsoft-bound automated business processes. They've been
working since to solve the problem and seem to have come up with a
solution. That is of immense importance to ODF adoption. If
enterprises can not feasibly migrate to ODF, then ODF goes no further
than than the folks who do not have to interact with Microsoft-bound
automated business processes. That in turn means that the rate of ODF
adoption should peak within the foreseeable future and I'm not pleased
with the prospect of ODF not being a viable solution for enterprises
except for new programs that have scant record-keeping requirements
such as laptop computer programs for students.

I don't think ODF will survive if we try to maintain a separate
low-end, lossy fidelity market while Microsoft continues to gobble up
what it doesn't already have in the enterprise market. We've been
picking the low-hanging fruit on ODF adoption and we're going to need
a ladder into the service oriented architectures of the world.

I am willing to share what I have learned about the Foundation's
ladder and I have no problems with sincere questions. But please,
Daniel, don't project your hostility toward Gary Edwards onto me and
please engage in a sincere discussion instead of approaching it as a
some kind of contest. I am not interested in debating you and I will
simply drop the conversation unless you change your approach. I am not
your punching bag.

Best regards,

Marbux