[odf-discuss] Miguel on OXML

[Alex Hudson]

marbux wrote:
> In the same article that echoed a fair number of highly
> debatable Microsoft talking points, I think it's understandable that
> folks would misunderstand a point that he didn't develop. Brevity is
> not invariably the right approach.

Possibly. I think people read arguments into his post that he didn't 
write, though. When he says "you can't implement a spreadsheet using 
ODF", he's correct - you can't, and he would know because he's written 
one. That doesn't make ODF useless for spreadsheets, though, since 
everyone "reverse engineers" (it's published, but I guess you have the 
bugs and things) the 123/Excel system that has been used since the year 
dot.

He could have been clearer I suppose; but then it's a blog post, and it 
was already long.

>> As I understand what the Foundation are doing with their plugin, this is
>> basically the approach they've taken: they translate to some level of
>> ODF, but then everything else is essentially Microsoft-specific tags
>> added in. More or less, OXML on top of ODF.
>
> Less. They go directly between ODF and the in-memory binary
> representation of the document, using Word's facility for native
> support of file formats. The tags they are using are the optional tags
> from the ODF spec's section 1.5 for handling of foreign elements.

It doesn't touch the in-memory representation as far as I can see - it 
uses Word's RTF interface, which is explicitly there for file format 
conversion.

I didn't say their ODF output wasn't valid ODF, but clearly the stuff 
they add isn't ODF per se in the same way that mixing HTML into ODF 
wouldn't be ODF. ODF allows extensions, but files with such extensions 
are still ODF + something, not ODF.

> They  aren't Microsoft-specific tags, although my understanding is that
> adding compatibility with the Microsoft binary formats was a strong
> consideration in the section's addition to the spec. But the
> procedures in that section are generic, not vendor-specific.

Well, they're not Microsoft-specific tags per se, you're right. But, no 
app other that Microsoft Office is going to understand the data in there 
by definition (if it was understandable, you'd presumably be able to 
translate it into actual OpenDocument).

It absolutely is fidelity versus interoperability, but ODF + extra tags 
as a Office document transport is much less interesting to me than real ODF.

>> One problem that Microsoft have, that Miguel correctly identified, is
>> that they've shipped Office 2007. That means they have _very little
>> room_ in which to resolve ballots.
>>
>
> If by "they" you mean Microsoft, I agree with your second sentence.
> But if you mean the folks who are supposed to be looking at Ecma 376's
> technical merits to decide whether to assert contradictions, there is
> plenty of room.

When I say "ballots" and "they", I'm really referring to Microsoft/Ecma 
in the final ballot stage - given the current evidence, I'm pretty sure 
the contradiction thing is unlikely to happen, and we don't really seem 
to be putting forward the right arguments.

> Miguel deserves stern rebuke for his failure to to call to his
> readers' attention that vendor-specific file format specifications are
> ineligible for the status of open international standards reveal.

Microsoft will hardly be the first to do this; e.g., Adobe et al. :)

>>    1. OXML passed, as-is, with few or minor changes (ODF only required
>>       "editorial" changes - and even that was a stretch - I'm not sure
>>       OXML will escape so easily)
>>    2. OXML passed, but with "significant" changes
>>    3. OXML not passed
>>
>> Look at it from Microsoft's point of view. 3. is obviously not a great
>> outcome for them; but is 2. preferable? If OXML was passed, but in a
>> format that was basically incompatible with Office 2007, that would be a
>> *huge* problem. I think the choices open to Microsoft are more or less 1
>> or 3. That helps us immensely.
>>
>
> Agreed, but there is an implicit 4th option to add to the list from
> Microsoft's standpoint. It's the one Microsoft is trying to avoid.
>
> 4. Abandon Ecma 376 and fully implement ODF.

That's not an outcome of the ISO process, though.

Given OXML is now shipping in Office 2007, and is available for Office 
2000+ , they cannot abandon it. The best hope we can have is that it is 
reconciled with ODF - the only other alternative for ODF is peaceful 
coexistance, really.

> There has been a lot of confusion on this list about the Foundation's
> da Vinci plug-in design goals. While full interoperability remains a
> goal for later versions that depend on changes to the ODF
> specification being made in version 1.2, full interoperability between
> Microsoft Office and conformant apps designed to the ODF 1.0
> specification is not a feasible goal as I understand it.

Well, to be fair, there hasn't really been any good information about 
the plugin, and I haven't heard of anyone getting the "Acme" version 
actually running (and obviously several people have tried).

It would be interesting to see what quality of ODF it currently outputs. 
I've tested the CleverAge plugin, and it does a pretty reasonable job of 
translating complex Office documents into ODF. It would be great to see 
the Foundation plugin write even better ODF, even if it only covers text 
documents right now.

> The Foundation's work is the only work I am aware of
> that attempts to fulfill this market requirement for ODF. To my
> knowledge, no one else is working on full fidelity migrations from the
> Office binaries to ODF.

You may well be right there. If they achieve full fidelity 
interoperability with ODF 1.2, I will be impressed.

Cheers,

Alex.