[odf-discuss] OOo OOXML filters

[marbux]

On 12/12/06, Daniel Carrera <daniel.carrera at zmsl.com> wrote:
> Popularity does not make it more proprietary. That's not what the word
> proprietary means.
>

Popularity is not a relevant issue. We are talking about two
proprietary formats here. MOOX is more proprietary in that it is
designed to impose a monopoly on far more than just the office suite
market.

> > And it is a single-vendor, one-way format.
>
> Not more so than .doc

Yes, far more so than .doc. Doc could only suck people into a
particular office suite. EOOXML sucks them into an entire stack of
proprietary business process software.
>
> > It features app-specific bug work-arounds;
>
> The same ones as .doc
>

Right.

> > hundreds of app-specific tags requiring reverse
> > engineering to replicate functions;
>
> Same ones as .doc
>
Right.

> > and unspecified binary blobs,
>
> Same ones as .doc
>
Right.

> In brief, there is nothing proprietary in MOOX that isn't in .doc.

Yes there is. Doc is only a file format. MOOX is a file format too,
but it is an XML file format designed as a communications protocol in
a tightly integrated business processes software stack. There is a
world of difference. Doc is a file format designed for
software-as-an-end-point. MOOX is a file format but also a
communications protocol for software-as-a-router-of-information. It's
XML, albeit weird XML that by design can not be fully implemented by
anyone but Microsoft.   Leave it to Microsoft to figure out how to own
an XML format.


There
> are proprietary things in .doc that are public and documented in MOOX.
>

That does not make MOOX an open standard. With 6,000-plus pages
involved and only those who have reverse engineered the DOC formats
able to do so, I have not attempted a 1:1 comparison. I have, however,
confirmed that many crucial parts of the MOOX specification are
closed. It can not be fully implemented by anyone but Microsoft and
hence is not open. One can argue that a chastity belt is more
revealing than a jump suit, but the young lady is still clothed in
either costume. MOOX is proprietary; it is not open, except in the
same sense than one might be partially pregnant.

> > EOOXML is also only a partial specification.
>
> So you make things _more_ proprietary by partially specifying them?
>
In this instance, yes. Until relatively recently, you could write your
own file converters for Word and produce several of the DOC formats
from another format or vice versa. Microsoft provided the
specifications for doing so.
<<http://support.microsoft.com/kb/q111716/>>. Microsoft has provided
no such documentation for EOOXML. Had it done so, it would be trivial
for others to add full native ODF support to Microsoft Office. So to
the extent that "proprietary" equates with "secrecy," EOOXML is more
proprietary than doc. Unless you make no qualitative assessment of
what is withheld and go only by word count.

But that is nothing new. Microsoft has tried to keep its file formats
a moving target for the last several years. This is just the biggest
move of the target so far. There will doubtless be more if Microsoft
gets away with ISO standardization for EOOXML. When Microsoft brags of
its interoperability, it is talking about the interoperability of its
own apps, not that of other people's apps with the Microsoft stack.


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

No, I am contrasting "proprietary" with "open."

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

I said "modified RTF."

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

Explained above.

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

That isn't my logic. MOOX is less open than doc, hence more
proprietary. To the above description, I'd add the fact that MOOX is
also armored by an assertion of patent rights. Doc isn't.

> > 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.
>
I'm not.

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

I didn't say it does. But whether MOOX is more proprietary than doc
does have bearing on whether OOo should or should not support MOOX.

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

Not so.

Best regards,

Marbux