[odf-discuss] OOo OOXML filters

Daniel Carrera daniel.carrera at zmsl.com
Tue Dec 12 15:59:30 EST 2006


On Tue, 2006-12-12 at 12:39 -0800, marbux wrote:
> > .doc is more proprietary than MOOX.
> 
> I think there are very strong arguments that it's the other way
> around.

Huh?

> The Word formats were used only in a word processor. MOOX is
> the new communications protocol for an entire stack of Microsoft
> business processes software.

Popularity does not make it more proprietary. That's not what the word
proprietary means.

> And it is a single-vendor, one-way format.

Not more so than .doc

> It features app-specific bug work-arounds;

The same ones as .doc

> hundreds of app-specific tags requiring reverse
> engineering to replicate functions;

Same ones as .doc

> and unspecified binary blobs,

Same ones as .doc

In brief, there is nothing proprietary in MOOX that isn't in .doc. There
are proprietary things in .doc that are public and documented in MOOX.

> EOOXML is also only a partial specification.

So you make things _more_ proprietary by partially specifying them?

> All of that ballyhooed
> "compatibility" with the binary formats it includes is only for the
> use of a single vendor's applications.

That's also not what the word proprietary means. You seem to confuse
"bad" and "dangerous" with "proprietary".

> Without the specifications for
> the binary formats, the modified RTF intermediary format,

You are quite convinced that it uses an intermediary RTF format, you
take it as a given. I just said that this would be a stupid idea. Why do
that round-about way where you are guaranteed to lose data in the
process? RTF is not nearly as extensive as MOOX or .doc or ODF.

Look, RTF doesn't even do macros.

> and documentation for the file conversion APIs

What the heck is that supposed to do with a format being proprietary?
The fact that MS Office is proprietary doesn't make MOOX _more_
proprietary that .doc. How do you work that out? Where's the logic
there? Let's go through this one step at a time:

1. MS Office is proprietary.
2. MOOX and .doc are two formats designed for/by MS.
3. Therefore, MOOX is _more_ proprietary than .doc.

I'm sorry, but the logic is faulty.

> ISO approval of EOOXML would be tantamount to the member
> governments granting Microsoft a monopoly on converting its legacy
> file formats to XML,

Which is definitely a very bad thing, and arguably MOOX is more
dangerous than .doc then; but that doesn't make it more proprietary.
That's just not what the word proprietary means. Call it dangerous, call
it whatever else you want, but don't abuse the word proprietary.

It's just like when people turn the word "FUD" into "anything I don't
like to hear" or even "anything inflamatory". Please use words in
accordance to their meaning.

> I can see principled arguments both for and against OOo supporting
> EOOXML and for and against various methods of doing so.

Whether OOo should or should not support MOOX has no bearing on the
question of whether MOOX is _more_ proprietary than .doc.

> But we should
> not allow ourselves to be seduced by the word "open" in EOOXML's name

I hardly am. Not any more than I am seduced by the word "Democratic" in
some country names...

> and in my opinion we can't just look at traditional office suites.
> EOOXML is all about Microsoft monopolizing the emerging business
> processes software market.

Absolutely, but that's no reason to misuse important words like "open"
and "proprietary". Don't confuse "more proprietary" with "more
dangerous". All your arguments have been to the effect that MOOX is more
dangerous to the future than .doc. Nothing to do with its proprietary
nature.

Daniel.
-- 
"I AM in shape. Round IS a shape."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20061212/afd213a9/attachment-0001.pgp


More information about the odf-discuss mailing list