[odf-discuss] Miguel on OXML
marbux at gmail.com
Thu Feb 1 16:28:30 EST 2007
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. It is far too easy to make mistakes
when you're just shooting from the hip without the discipline of
developing your points.
> >> 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
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.)
> 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.
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. There are some more tags they'd like to use that they want
to have added in ODF v. 1.2, but as I recall they aren't using them
yet. The present barrier is that the extant version of OOo doesn't
support the options in ODF section 1.5. Thomas says he has them
implemented in the next version of KWord.
> > 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).
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. The WordPerfect binary file format already does
this for cross-version compatibility of files generated by WordPerfect
6.0 through the latest version. E.g., I have WordPerfect 11 and can
round-trip files with edits at both ends with someone running WP 6.0
and with someone running WP 12. The big problem is that the ODF 1.0
and 1.1 conformance sections are defective in that they makes things
optional that should have been mandatory. The important thing is that
ODF 1.2 files will be able to round-trip between apps without loss of
data needed by app 1 just because app 2 doesn't implement an identical
feature set. App 2 is going to have to preserve any unrecognized App 1
tags, enclosed by the <foreign> tags. So e.g., Kword will be able to
exchange files with MS Word and any metadata needed by Word won't get
lost in the exchange back and forth. It should also mean that OOo v. 3
will be able to pass documents back and forth with OOo v. 6 without
loss of metadata that only makes sense to version 6. And that
ODF-based outliner I hope someone will develop some day will be able
to pass documents back and forth with KWord without loss of tags the
more featureful app generates.
Right now, the ODF spec makes that optional behavior. ODF 1.2 will
hopefully cure that defect in the standard.
> 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.
> 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.
I disagree, except for the few technical criticisms that were in
error. A lot of people have misunderstood what "contradictions" within
the meaning of the JTC-1 Directives. I'm one of them. I'm working on a
blog article that should clear up a lot of the confusion on the issue.
Hopefully that will be published later today. I'll announce it on the
list when I do.
> > 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. :)
Well, the fact that someone else murdered someone before I do doesn't
excuse me doing it. :-)
> > 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.
I disagree. Microsoft has deprecated Office file formats regularly.
For example, there isn't any Microsoft Office 2003 XML support in
Office 2007. If ISO says no to Microsoft having its own personal
standard, Microsoft will either fully support conformant ODF or they
will have to abandon the Office government software business and the
business of all those who want to exchange office productivity
software files with government. While I don't have the benefit of
Steve Ballmer's advice on the issue, I find it very hard to believe
that Microsoft would just kiss all that business goodbye. All that
would be different is that they would have to compete based on
quality, press, and customer loyalty instead of monopoly vendor
lock-in file formats.
Not that I wouldn't expect new lock-in tactics not reflected in the
office file formats that provide interoperability with other vendors'
apps. E.g., Microsoft could support an ODF interoperability subset of
an ODF versdion with Office extensions in their own apps' namespace
within ODF files. It could even implement their extensions using
binary blobs to make it harder for other vendors to match features,
then add gobs of features to differentiate their product. It isn't the
end of the world for Microsoft if it has to support a conformant
implementation of ODF. It's just that Microsoft wouldn't be able to
maintain its monopoly share of the office software market. It's
having problems doing so anyway as OOo continues to win really
significant market share. I suspect that achieving ISO standardization
for Ecma 376 would not reverse that trend, only stop it from
Microsoft's real hopes for reversing the trend, I believe, are the
Sharepoint-Exchange server hubs and the stack of new apps Microsoft is
building around them. But Microsoft has to win the ISO Ecma 376
standardization battle for that strategy to work *and* it has to stay
way out ahead of the ODF developers when it comes to business
processes software. That's a pretty tall order, particularly with a
proprietary software business model that is in rapid decline from its
ascendancy in terms of market share. I'm not at all sure that
Microsoft has enough developers to outpace its competition once the
competition wakes up to Microsoft's new strategy. We just need to
break a bunch of developers out of the software-as-end-point mind set
and watch them develop from the software-as-routers-of-information
mind set. E.g., the Apache Foundation clearly "gets it."
<http://cocoon.apache.org/2.1/features.html>. Others will follow.
> > 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).
Yes, although I think the information is starting to flow. On the
problems with getting the proof of concept running, I forwarded the
relevant posts to the Foundation but haven't heard back from them yet
on that topic.
> 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 problem here is that a "reasonable job" isn't good enough when it
comes to wholly automated business processes. The market requirement
there is full fidelity. The Clever Age plugin might get people by for
documents that can be manually inspected. But we have Steve Ballmer
and Miguel de Icaza's word that it will not achieve full fidelity. I
have no doubt of Steve Ballmer's intention to carry through his
intentions in that regard. Another major problem with the Clever Age
plugin is that it doesn't provide native support for ODF in Office.
I.e., the traditional File Save commands can't work. That's
practically a guarantee that any network that tried to standardize on
ODF using the Clever Age plugin would wind up with a real mess in
terms of documents saved to multiple file formats. Hitting Control+S
every few minutes isn't an easy habit to break. :-)
If you have any ideas on how to test documents that don't involve the
Foundation releasing the plug-in before OASIS approves ODF 1.2, I'd be
happy to pass them on.
> > 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.
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.
My computer's reputation has never been besmirched by the presence of
Microsoft Office and it won't before Microsoft stops playing vendor
lock-in games. :-)
More information about the odf-discuss