[odf-discuss] A story of TIFF

[Daniel Carrera]

On Sun, 2007-02-04 at 16:28 -0800, marbux wrote:
> > 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.

I am not trying to make a strawman. Where is the strawman? You said:

"My understanding is that the current version using the proposed ODF 1.2
changes already achieves near-perfect interop in both directions"

I'm saying that I don't see how this is possible, since ODF 1.2 is not
implemented elsewhere. Interoperability requires more than one
application. You cannot argue interoperability until there is at least
one other application with which you can interoperate.

> 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."

At no point have I suggested that I don't understand that the ODF plugin
exports binary blobs as dark matter and plans to put a flag on them. You
seem to think that this is relevant, but this what I said:

"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."

That statement remains. I am aware that you plan to export unknown
binary blobs and flagging them. This, however, is not a feature that
makes the unknown binary blobs known. It merely marks them as unknown.

> Nope. I was clear in saying that the plugin depends on features not
> presently supported in ODF.

Which conflicts with your claim "the current version using the proposed
ODF 1.2 changes already achieves near-perfect interop in both
directions".

> > 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.

This is relevant information. Thank you.

> 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.

You are using one tool that Clever Age cannot use: extensions. If Clever
Age started adding non-ODF tags to their files you and the rest of the
world would be crying bloody murder. "conversion" would really be a lot
easier if you allow yourself to use extensions. For example, you could
just grab an EOOXML file, put <office:document> tags around it and
persto! it is a valid ODF file as defined in section 1.5. But of course,
we don't _want_ Clever Age to take that approach, even if it means "full
fidelity".

> Second, the allowance for wrapping dark objects in
> EOOXML tags testifies that MOOXML is not entirely XML but also
> includes proprietary binary blobs.

Could this same argument not be made for ODF then? "the allowance for
wrapping dark objects in ODF tags testifies that ODF is not entirely XML
but also includes proprietary binary blobs". Of course, I don't believe
this. I'm just offering a word of caution, lest less scrupulous person
use your argument against you on a public blog.


> 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.

I think you missed my argument. I posit that an OXML-based approach has
the same benefits as the Foundation plugin. Since I certainly do not
support an OXML-based approach, and I suspect few people on this list
will, I find it hard to support the Foundation plugin. I think that
putting OXML inside ODF is *bad*. I think that putting binary blobs
inside ODF is *very**bad*. I hope this clarifies the misunderstanding.


> 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.

Let me see if I understand your position: You claim that EOOXML cannot
legitimately (ie, using real tags) represent future documents. That
Microsoft will fill it with binary blobs going forward. Therefore,
EOOXML cannot be relied on for conversion. Correct?

I don't know the merit of your premise, so I will not dispute it. But
those blobs then have to be stored in the EOOXML document, and if you
just let through tags that you can't convert, those blobs end up in the
ODF. You still get "100% fidelity". A blob is a blob is a blob and it'll
still be impenetrable. But this would also be true if you got the blob
directly from the in-memory binary representation. It's still a blob.


> > 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,

I do not. You need to read more carefully and imagine less. I never say,
or imply, or intend to imply, that the problem of interop are fixed by
adding binary (or even non-binary) dark objects.

> 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.

Using OXML as an extension of ODF is an example of a "solution" that has
dark objects that are less dark than in the Foundation plugin. If you
agree with me that using OXML as an extension of ODF is a bad idea, by
my argument, the Foundation plugin is too. Both solutions have the same
benefits: 100% fidelity, wrapping dark objects, etc. In the OXML one the
dark objects are mostly documented XML, which is an improvement over
just binary objects. If you don't support the OXML extension idea (I
don't) I don't see how you can logically support a binary object idea.

> 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.

Gary's "proposed solution" for interop is to flag binary objects and
hope that applications will figure out how to deal with them. Have I
missed a solution to the dark object problem?

> The difference is
> that they have proposed a solution to the dark objects problem and you
> have not.

You seem unable to articulate what this solution is, beyond "let's hope
applications will figure it out". If that's the solution, then it is
surely better to hope that applications will figure out what
'useSpacingLikeWord95' means instead of hoping that they'll figure out
what '0TbUF0IZ+XQCXGk' means. Especially since, after they spend a few
years trying to decode it, they'll just find out that 0TbUF0IZ+XQCXGk
means 'useSpacingLikeWord95'.


> They address the problem through the ODF foreign metadata
> tags, a proposed MS Office ODF interop subset,

Do you understand what a subset is? It looks like you don't. Please read
this:

http://en.wikipedia.org/wiki/Subset

An interoperability subset for MS Office has nothing to do with dark
objects. In brief:

* Dark objects relate to MSO->ODF interop.
* MSO subset relates to ODF->MSO interop.

>  and five proposed ODF
> extensions that allow adequate description of the blobs" content as
> more is learned about them.

That's fantastic, and kudos for that. Those same extensions can be used
to map portions of EOOXML-stored documents.


>  Meanwhile, their approach already has
> achieved near-perfect fidelity.

I thought it was perfect fidelity. Heck, you can get perfect fidelity by
just dumping the entire in-memory structure inside a tag.

> Word's primitive page layout engine

I really hope you realize that you are talking about two different
processes. You seem to be mixing MSO->ODF with ODF->MSO. Whatever
limitations word's layout engine has are ODF->MSO. The discussion of
extensions is MSO->ODF.

> 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.

You keep yapping about that. I keep asking you to read section 1.5. It's
not rocket science, really, and it's less than a page. The relevant
section is only two paragraphs. Here it is:

<quote>
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.

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


> But please,
> Daniel, don't project your hostility toward Gary Edwards onto me

I have no hostility at all towards Gary Edwards. Why should I? Wouldn't
it be more logical that if I have hostility towards anyone it be towards
you? What has Gary done to me?

> and please engage in a sincere discussion

I hope you will follow your own advice. I think you are too reluctant to
see flaws in the solution you prefer. I see problems with it. It has
taken you a long time to understand some fairly basic points about it,
like what section 1.5 of ODF says. In an attempt to show the problem, I
mention another alternative which you naturally do not support (I don't
support it either), and I argue that this alternative has the same
benefits. It seems like a good way to make a point.

Best,
Daniel.
-- 
May you live in interesting times.
May people in high places take notice of you.
May all your wishes come true.
  -- Chinese curse.