I wanted to post a quick reaction to the latest Microsoft bullshit announcement, in which they reportedly plan to "add native support for ODF 1.1". The way they put is very succinct, intentionally probably, and it opens the door for wild guesses.
First of all, Microsoft is a huge Office licensing monopoly. It's so big it even surpasses Windows in sales. Any decline in Office licensing would be dramatic for Microsoft's future. With that alone, you know that any announcement from Microsoft that they are willing to interoperate with other people's software, namely applications, should be taken with a grain of salt.
Here is how, with the release of Office 2007, Microsoft intends to keep their monopoly in Office licensing :
2Expand
OOXML is defective by design: Microsoft latest bullshit : native support of ODF in Office 2007
Stephane is right on target. This is a must read for anyone trying to understand ISO approval of OOXML, and the sudden change of mind at Microsoft to support ODF!
1Expand
OOXML is defective by design: Follow up on Microsoft latest bullshit announcement
Stephane Rodriquez sums it up: Microsoft has won ...
"Future of OOXML? There are two answers. Frankly, who freaking cares the paper? This paper will ALWAYS be at odds with the actual Office implementation. We have a good example for the time being, but it has always been the case. What about the actual file format then? It will be the subject of reverse engineering from implementers whose only recourse is to catch up all the undocumented stuff. Make no mistake though, now it's about applications, not documents anymore."
"Conclusion : if you are still in the OOXML conspiracy game, about time to move on guys. "
1Expand
IDABC - EU: Microsoft's ODF-support draws mixed reactions
This is nonsense. Whether an organizations standardizes on ODF or OOXML, the "interoperability" they seek will still be based on every desktop running the same application. Neither format enables the interchange of documents between different applications - even if those applications properly implement the format standard. Anyone can prove this for themselves. Simply shuttle a few OpenOffice ODF documents between Symphony, Novell Office and Google Docs. Then weep. At least with MSOffice-OOXMLyou can exchange documents between different versions of MSOffice. Even though OpenOffice, Symphony and Novell Office are based on the same code base, interop might as well be zero.
Besides; what end users really want from a modern desktop office suite is collaborative editing of web ready documents. This discussion is so last century - 1995!
more fromec.europa.eu
5Expand
The Fall of Microsoft Office
More confusion about the MS announcement of native support for ODF, with delayed support for whatever ISO finally determines to be ISO 29500; "OOXML". Damn but these guys are all twisted up about this. The truth is, ISO National Bodies traded their vote in favor of OOXML for MSOffice support for ODF and Microsoft's joining the OASIS ODF TC. It's not complicated. MS wants ISO approval of OOXML because it established MSOffice as a "standards" editor. The rest of this kurfufull is all about anti trust concerns and Microsoft's need to put htose concerns to bed before the world figures out that they are leveraging the MS desktop monopoly into an MS Web monopoly. ISO approval of OOXML is the final piece of very complex puzzle.
The harmonization of OOXML-ODF is impossible. MS knows this. So why not join OASIS ODF TC if it means putting aside the anti trust claims from ISO NB's and getting that all important standardization of OOXML? Both ODF and OOXML are both XML encodings of entirely application specific binary formats. There is no possible to way to reconcile the file formats without also reconciling the applications! Incuding feature sets and layout engines!!!! Impossible!!
The real game is the transition from client/server to the emerging client/Web-Stack/server model. MS is the "client" in client/server. No way were they about to give that up without a plan to control the transition of MSOffice documents to the emerging client/Web-Stack/server model. They sought to fully control the formats, protocols and API's of this new model. ISO handed it to them.
The thing to watch is the MSOffice SDK where one can find a very cool OOXML <> XAML converter. XAML is totally proprietary, but "web ready". Meaning, MSOffice is a "web ready" application. It's just that the web readiness is 100% MS .NET-Silverlight.
The great transition to client/Web-Stack/server is now on. Thanks to ISO. All this ODF stuff is just background noise designed to quiet the anti trust crowd. Despicable, but well done.
~ge~
more fromwww.fool.com
3Expand
Office 2007 won't support ISO's OOXML - SD Times On The Web
Microsoft to support PDF, ODF 1.1 and ISO OOXML in MSOffice 14. The company will also join the OASIS ODF TC and working group for ISO PDF.
more fromwww.sdtimes.com
1Expand
ConsortiumInfo.org - Standards to the People! (Updated Twice)
Strange demands from Andy Updegrove: "I call on Ecma to withdraw OOXML from ISO and keep control of it themselves. We need it for legacy documents...."
Why would anyone want Ecma to take back control of MSOffice-OOXML from ISO? The best circumstance would be for OASIS to turn OpenOffice-ODF over to the same ISO JTC-S1, where they can finally begin the difficult (if not impossible) harmonization process. Let me add on other thing; the place for ISO to begin harmonization is "presentation". We desperately need a standardized presentation model useful to MSOffice-OOXML, OpenOffice-ODF, XHTML and HTML. I suggest they start with CSS 3, and work back into ODF - OOXML. But that's just me :)
more fromwww.consortiuminfo.org
1Expand
Griffin Brown Weblog - ODF validation for the cognoscenti
Rob Weir gets royally spanked. And so does the notion that ODF is somehow "interoperable". Big Time.
more fromwww.griffinbrown.co.uk
1Expand
OOXML: The next step - Interop at the International Standards legal level | Marbux - Weir - Ian [odf-discuss]
Marbux at his best! Here he responds to Rob Weir's ODF v 1.2 arguments with a legal dissertation on International Standards, ISO, the WTO, and the key issue of interoperability and what it must mean. Excellent!
more fromlists.opendocumentfellowship.com
1Expand
OOXML and ODF: The next step | [odf-discuss] Marbux Responds!
Excellent legal argument by the legendary marbux concerning OOXML and ODF itneroperability. Covers ISO Interop Requirements and the demands of International Trade Agreements. Key to this thread is ODF v 1.2 and what must be done to bring ODF into legal compliance with International demands.
more fromlists.opendocumentfellowship.com
1Expand
OOXML OPS and the GPL: A disappointing surprise from the SFLC | Gray Matter
Scott B comment on the OOXML OPS and GPL controversy. Great comments from Bruce Perens also.
more fromblogs.technet.com
1Expand
OOXML and ISO: The Process Challenge - A Predictable Path | Matusow's Blog
Scott B responds to Matusow blathering with a list of ISO changes that should be made given the OOXML fiasco, but won't.
more fromblogs.msdn.com
1Expand
OOXML: MSOffice Open XML - Where The Rubber Meets The Road | Matusow's Blog
Perhaps the single best comment i've ever read concerning OOXML and the value of standards. Very concise and too the point. Thanks you Scott B!
more fromblogs.msdn.com
1Expand
Microsoft's Great Besmirching | Linux Journal
Glyn Moody provides a summary of the destruction of ISO
more fromwww.linuxjournal.com
1Expand
Knowledge Ecology International - KEI Statement on OOXML vote by ISO
more fromwww.keionline.org
1Expand
Microsoft OOXML standardization bid: The clock is ticking | All about Microsoft | ZDNet.com
more fromblogs.zdnet.com
1Expand
The Stockholm Syndrom at ISO | ODF Editor Says ODF Loses If OOXML Does | Slashdot
Response to Yoon Kit's comments that Patrick Durusau is caught between a rock and hard place. His ISO JTC-1 group is now overwhelmed with MS OOXML supporters!
more fromslashdot.org
1Expand
The Charter Dilemma | ODF Editor Says ODF Loses If OOXML Does | Slashdot
This commentary follows the Stockholm Syndrom post, which is itself in the thread based on Yoon Kit's Open Malaysia comments concerning the dilemma Patrick Durusau is in; the JTC-1 is now filled with Microsoft OOXML supporters!
more fromtech.slashdot.org
1Expand
ODF Editor Says ODF Loses If OOXML Does | Slashdot
ge comments about Patrick Durusau and his surprising change of position in support of ISO approval of OOXML
more fromtech.slashdot.org
1Expand
India Votes Against OOXML | Slashdot discussion
MSOffice SDK OOXML <> XAML converter. It is all about the web!!!!!!
more frompolitics.slashdot.org
Notation: * = Private bookmark and comment|… = Clipping [?] | … = Public highlight [?]
OpenOffice.org has an internal layout engine with an implementation model very different from that of the MSOffice editors. The differentials of internal representation of basic document structures is very problematic to roundtrip conversion processes. ODF is an XML encoding of the OpenOffice internal representation, sometimes called the "binary dump" or in-memory-binary-representation. OOXML is similarly an XML encoding of the MSOffice internal representation.
The layout engine differences (internal representation) results in serious incompatibilities at level of file format "presentation" layers. While it's easy to exchange "content", "presentation" is impossibly application specific.
Given enough time, one would hope that the entire presentation layer of OpenOffice-ODF could be fully described in terms of both syntax and semantics. After five years and a half years of work, ODF has not made much progress in this area. Once the presentation semantics are fully documented, the plan was to then "neutralize" the application specific aspects with more generic representations.
If you go back to January 2003, you'll find in the eMail archives of the OASIS ODF TC some remarkable discussions concerning proposals to throw out the OpenOffice XML submission, and start from scratch with an entirely application independent specification. This was suggested by Phil Boutros (Stellent), and supported by Corel, Boeing, ArborText, and SpeedLegal (Jason Harrop). In the end however, Sun prevailed with the promise that the obviously application specific aspects of ODF would be fully documented and neutralized. Sadly this has yet to happen. Worse, the OASIS routine of highjacking W3C namespaces further confuses things since these application specific implementations are similarly undocumented.
IMHO i believe there is a solution to this mess. But it's not going to be what most expect; the harmonizing of ODF and OOXML. That isn't going to work - ever! For harmonization to work, one would have to harmonize OpenOffice and MSOffice by rebuilding the aging layout engines. And that isn't going to happen.
A more reasonable approach would be to target an application independent format that is entirely neutral. The truth is that you can not ask an established application (layout engine and feature set) to implement another applications internal representation model. What you can do though is target a neutral format that is flexible and generic at the document structure level.
My favorite "neutral" format is the WebKit document model. The primary reason is that it's "web-ready". Who in their right minds would today target any document format not "web-ready"? Yet that's what we did with ODF.
I fully believe it is possible to set up round trip conversions from both OpenOffice and MSOffice to the advanced but highly interoperable WebKit flow document model. Don't even try to re invent the layout engines of legacy applications. Set as your target a neutral, application independent format that is Web-ready" and useful across the widest span of devices, desktop, and web application and service systems. Then never look back.
I hope you will consider joining marbux and i over at the Diigo "Future of the Web" group. Your contributions would be much appreciated. Besides, all my blogging is there :)
One last point; i did get your eMail concerning RelaxNG. But it took some time. I had lost my openstack.us domain for some 90 days. When i finally got it reinstated, a ton of eMails showed up. My apologies. But you are absolutely right in your assesment. I have asked Florian and Marbux to confirm this and perhaps explain how this came to be. The issue is once again that of Sun highjacking namespaces and committing two applications specific crimes in the process. The first fault is that the implementation of the digital signature standard is limited to exactly what OpenOffice chooses to implement. The second fault is that the OpenOffice limited implementation is nowhere documented!
The highjacking of namespaces really came to head in the metadata subcommittee where the OpenDocument Foundation had successfully inserted into the requirements document a model for using RDF to describe in a very neutral and generic way all of the problematic presentation aspects. Meaning, we believed that format and styling information is simply object metadata. We really thoguht we could neutralize the application specific problems of ODF using a metadata approach. Sun however had different ideas. They ended up convincing IBM and Patrick Durusau to limit the use of XML ID to only those elements approved and implemented in OpenOffice. Once this monstrous example of application specific crap was approved by the OASIS TC, i quit ODf.
Hope all is well,
~ge~