[odf-discuss] Miguel on OXML

[Alex Hudson]

marbux wrote:
> On 2/1/07, Alex Hudson <alex at stratagia.co.uk> wrote:
>> marbux wrote:
>> He could have been clearer I suppose; but then it's a blog post, and it
>> was already long.
> Then it would have been more appropriate to break his article into two
> articles so he could do them justice. One of the major problems of
> articles that don't develop their points is that the process leads to
> error and misunderstanding. For example, had Miguel developed his
> points it would have required some fact-checking and that should have
> resulted in far fewer errors.

Well, let's go back to the original point of his blog post. The points 
he was making weren't in support of his opinion about whether or not 
OXML could/should be standardised.

What he _was_ saying was that equating OXML with .doc, CIFS, media 
server etc. in the context of the EU litigation was, in his opinion, 
wrong. Everything up to what he was saying about the size of the 
specification etc. was about that. Personally; I suspect he's right - if 
the Samba people got the same kind of documentation that the 
OpenOffice.org people now have access to, they'd be made up.

If you assume that his points were made to back up his opinion about 
OXML's standardisation status, I can see how you don't think it's 
logically supported, but he wasn't making that argument.

> Sorry, by "directly" I meant that MOOX was not involved in the
> process. I understood the statement I was responding to as leaving
> room to be misunderstood as suggesting that OOXML was an intermediary
> in the process. (I'm not suggesting you intended it that way.)

Oh, no, totally. I was drawing an analogy between encoding RTF in XML 
(which is effectively what the Foundation plugin) and OXML, but I didn't 
mean to imply OXML was involved.

> My understanding is that the stuff they "add" are the options allowed
> in the present ODF 1.5 conformance section and are not extensions to
> the spec.

Well, I would encourage you to look at Section 1.5 of ODF - it's only a 
couple of paragraphs :) It starts:

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

So, "extension to the spec." is a relative matter. Anything which is 
part of an ODF file by virtue of 1.5 is not part of the OpenDocument 
specification - it's foreign. Now, obviously, the format contemplates 
these foreign elements, so are they really extensions?

I would call it an extension, because any information you include in ODF 
by virtue of 1.5 breaks interoperability, by definition - if your ODF 
application outputs it, no other ODF application will understand it.

 From Gary's blog, I understand that the addition in ODF 1.2 is that any 
data contained in these extensions must not be thrown away by compliant 
apps (assuming that ODF 1.2 comes out the way we think it could). But, 
that doesn't give ODF-compliant apps any extra understanding of what 
that foreign data is.


> Likewise, I expect the WordPerfect implementation of ODF 1.0 is going
> to hide some stuff in the foreign elements tags that other apps won't
> be able to understand.

That's possible, but it would be sad. OpenOffice.org manages to do 
without them (for the most part), and  I suspect KOffice doesn't use 
them. Having foreign elements breaks interoperability, and if ODF 
documents are not interoperable between different applications, there 
really isn't much point to using ODF.

>> It absolutely is fidelity versus interoperability, but ODF + extra tags
>> as a Office document transport is much less interesting to me than 
>> real ODF.
>>
>
> It sounds like you've misunderstood something. As explained above, the
> ODF generated using the plugin does produce "real" ODF. It just
> implements features that are optional in the current spec that
> apparently no one else implemented because they are optional. The
> plugin isn't sticking tags in an application-specific namespace as I
> understand the situation.

Well, I'm basing this on what I read from the Foundation blog at fr0mat.net:

"The easy solution is to simply wrap (enclose) these dark objects in 
foreign   element tags. While this method is perfectly legal ODF because 
of its strong   interoperability features, see   e.g., ODF v. 1.1   
section   1.5, 
<http://develop.opendocumentfellowship.org/spec/?page=1#1.5> it comes at 
the cost of interoperability with other ODF ready   applications. Sure, 
inside da Vinci enabled Microsoft Word the conversions and   handling 
are perfect. Absolutely perfect. Send one of these dark object loaded   
documents to OpenOffice though and the application has no idea what to 
do with   it."

That's saying that the foreign elements stored in the ODF files are 
basically data that can only be understood by Microsoft Office. If you 
put foreign data in ODF, it's legal according to the spec. - it says you 
can do that - but it's not OpenDocument, in that no other ODF 
application will understand that.

Even if OOo implemented 1.5 fully, including the MAY parts which will 
become MUST in 1.2, it's still not going to understand these bits of 
Word data in the ODF files - all that will change is that OOo won't lose 
those bits of foreign data. It's a bit like handing me a document in a 
foreign language: I can promise to hand it back to you in the future 
without altering it, but I don't understand a word of what's written ;)

But that's what I meant by not being interested in "full fidelity" ODF 
if it comes at the expense of interoperability. For me, if I load an ODF 
text file in OOo or KWord, it should basically work, and the application 
having "no idea what to do with it" is not a useful result.

> Me too. They've already run into a roadblock that needs resolution. As
> I understand it, Microsoft changed Word 2007 between the last public
> beta and the platinum version, which now insists on treating every
> file in Zip format as an OOXML file. I haven't confirmed that myself.

I'm actually not at all surprised by that, and I really don't think it 
has anything to do with lock-in - it has everything to do with the fact 
that the world's webservers do not understand ZIP/JAR based container 
formats.

We've seen this with ODF already - nothing delivers ODF files correctly 
out of the box, and even though I filed patches with Apache probably 
years ago now, it still doesn't. Most ODF docs I try to download off 
other people's webservers don't work.

Microsoft almost certainly did this so that people could download OXML 
documents from the internet and not have them appear as Zip files. Given 
that even the open source community can't get traction on this issue, it 
doesn't surprise me. It definitely sucks, though :(

Cheers,

Alex.