Group items tagged

Exactly! It's not that ODF is under-specified. It's that ODF can't be fully specified until OpenOffice is completely documented and capable of supporting expected features. There is this famous quote from Sun's Svante Schubert that pretty much says it all; "Nothing goes into the ODF specification unless it's supported by OpenOffice". The statement was made at a meeting of the OASIS ODF Metadata SC while discussing the controversial use of "XML ID". IBM's Elias Torres, of RDFa fame, was passionately arguing that use of the XML ID should be left open to all developers. Sun had taken the position that XML ID should be limited to only a handful of elements supported by OpenOffice. The discussion acutally got far worse than the quote would indicate. Elias compromised his arguments suggesting that we should allow developers to have at it with XML ID for at least one year, and then revisit the issue. This suggestion lead to a discussion of how developers implementing elements with metadata would notify the metadata sub committee of their use case. A discussion list was proposed. The idea being that developers would send in their use cases and the oligarchs on the sub c would approve or disprove. Incredibly, this suggestions was shot down by Bruce d'Arcus (OpenDocument Foundation). Bruce thought that any developer needing metadata support for particular elements should have to join the OASIS ODF Metadata SC like everyone else before their needs would be considered. ( i.e. - like the other oligarchs). At the next weeks meeting, Rob Weir showed up with a list of 14 spreadsheet related elements that IBM needed XML ID support for. Sun representatives Svante Schubert and Michael Brauer immediately approved the use, agreeing that OpenOffice would support that implementation. This how things work at OASIS ODF. Ever wonder why SVG or XForms support in ODF is so limited? It's because the specification directly reflects the limits of the OpenOffice implement

Sorry. Diigo cut my comment off about half way through. I've complained to Wade and Maggie about this problem, especially how it impacts and cripples the "Group Auto-Blog Post" feature . Months have gone by. Yet still the issue remains.

Rick Jellife weighs in on the OpenOffice ODF- MSOffice OpenXML interop embroglio. His take is to focus on Classes of Fidelity, providing us with a comparative table of fidelity categories. I wonder though if this über document processing approach is anywhere near consistent with the common sense meaning of interoperability to average end-users? IMHO, end-users interpret "interoperability" to mean that compliant applications can exchange documents without loss of information. "..... In my blog last year Is ODF the new RTF or the new .DOC? Can it be both? Do we need either? I raised the question of whether ODF would replace RTF or DOC. I think this issue has come back with a bang with the release of Office 2007 SP2, and I'd like to give another pointer to it for readers who missed it first time around.... "...... OASIS ODF TC has some kind of conformance and testing wing at work, but it is not at all clear that they will deliver anything in this kind of area. Without targetting these classes, ODF's breezy conformance requirements means that ODF conforment software can deliver vastly different kinds of fidelity, yet still accord to the letter of the law (and, indeed, to the spirit of the ODF spec, which allows so many holes) which will cause frustration all-around....." Ouch!

Wow! The ODF peasants with pitchforks are have taken to the streets, and ISO document expert Alex Brown is taking them on. The volumes of traffic generated by any discussion of the ISO XML document wars continues to amaze. It's very one sided though. The basic problem seems to be that ISO has accepted two XML document format standards, OOXML and ODF, with OOXML being held to a higher set of expectations than ODF. Alex would do well if he could step back from the OOXML - ODF war, and move the discussion to something like the theoretical IDABC ODEF: the European "Open Document Exchange Formats" design. With ODEF as single set of XML format requirements against which both OOXML and ODF can be measured and compared, Alex might be able to neutralize the heated emotions of angry Open Source - Open Standards - Open Web supporters, who mistakenly think ODF measures up to ODEF expectations and requirements. Trying to compare ODF to OOXML isn't getting us anywhere. At some point, we have to ask ourselves what is it that we want from a standardized XML document format. Having participated in both the Massachusetts pilot study and the California pilot discussions, i have to say that the public expectations were that XML formats would have a basic set of characteristics: open markup; structured separation of content, presentation and logic; high level interoperability (exchange), and Web ready. These are basic "must have" expectations. XML formats were expected to be "better" than 1998 HTML-CSS. But when we apply the basic set of expectations, todays HTML+ (webkit HTML5, CSS4, SVG/Canvas, JS, JS Libs) turns out to be a far better format. Where the XML formats really fall off the wagon are the interoperability and Web ready expectations. For the life of me i don't see how anyone can compare ODF or OOXML interoperability with that of HTML+. And of course, HTML+ is the native language/for

Jesper Lund Stocholm was kind enough to point out that, once again, GrokLaw is stoking the fires of the XML document wars. This time PJ takes on Alex Brown, of the ISO SC34 document standards group convenor. And Alex responds ... and responds ... and responds. of course, the attacks keep coming! I left Jesper a rather lengthy comment at: http://tinyurl.com/document-wars

see the sticky notes on this one

This section of the Slashdot discussion of the LinuxWorld "Game Over" article concerns itself with RTF and Microsoft. ACME 376 "decodes" and converts MS RTF to XML encoded RTF. The full da Vinci process follows this chain: imbr<>MS RTF<>ACME 376<>InfoSet = output target file format MS RTF is the internal structuring stage that all in-memory-binary-representation are sent through with any conversion. Including the conversion of imbr to OOXML The OOXML plugin process looks like this: imbr<>MS RTF<>OOXML The da Vinci ODF process looks like this: imbr<>MS RTF<>ACME<>InfoSet<>ODF The da Vinci CDF process outputs to CDF instead of ODFThe reason we need to output to something other than ODF is that the OASIS ODF TC has no interest in provisioning the ODF specification with much needed iX "interoperability eXtensions". the iX eXtensions were designed to accomodate the high fidelity "round trip" conversion of existing MS documents to ODF while establishing a high level of interoperability with existing MS applications and workgroup processes.

Great quote from Eric Knorr.  He hits the nail on the head here, pointing out the problem Office 2.0  Web Apps and SaaS apps face:  If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios.  If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process.  The only way to overcome that kind of a split is to take the entire process.  Which is difficult for lightweight mashup happy web wonders to do.

Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft.  As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life.  At any time Microsoft can swoop in and take it all.

Today, the MSOffice OOXML file format displays perfectly in a browser.  It's 100% web ready, but only the MS Stack of applications gets to play.  Web wonders are not likely to recieve a Redmond invite now or ever.

Which brings us to the issue of the da Vinci plug-in for MSOffice.  da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys.  It can achieve the same high fidelity "round trip" conversion that OOXML is capable of.  Maybe even better. 

The problem for da Vinci isn't conversion fidlelity.  Nor is it capturing  business process important VBa scripts, macros, OLE, and security settings.  da Vinci can do that just fine.  The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!!  For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF

The battle to break ODF away from being limited to only those features supported by Sun's OpenOffice/StarOffice continues.  This eMail thread sets the stage for the upcoming presentation of the metadata proposal to the ODF mainline TC.

SEction 1.4.3 of the metadata proposal is a list of existign ODF elements that developers can apply RDF to.  And the reason given fo rwhy the list is so constrained?  Svante Schubert, co-editor and Sun employee has claimed on more than a few occassions that the reason for limiting the lis tis that Sun will only support RDF on those particular ODF elements in OpenOffice/StarOffice.  Therefore, everyone is similarly limited!

I kid you not. 
~ge~

Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled  Microsoft trounces pro-ODF forces in state battles over open document formats.


Andy believes that it is the failure of state legislators to do their job that accounts for these failures.  He provides three reasons for this being a a failure of legislative duty.  The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors. 


The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.


Andy puts it this way, "
  

And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats.  You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe

This great.  Read the comemnts with Bruce!  The chickens have come home to roost.

Archives of all OASIS ODF TC disussions.  Does not include Metadata, Formula or Accessibility lists

This quote from Chalres Schultz is ridiculous. Because Novell is not allowed to commit code to OpenOffice, they must maintain a separate code base of extensions and improvements. With each build of OpenOffice, Novell must reintegrate their changes into the code base, making for a managerial nightmare. When Novell does have improvements that Sun wants though, there is no end to the hoops of fire the Sun developers will jump through to get it. The Field Enhancement routine written by Novell's Florian Router is one of those improvements that Sun had to have. Sun even went so far as to arguing for changes in the way ODF implements fields to accomodate the Novell improvements! It's important to note however that Sun did not support the ODF Field Enhancements UNTIL Novell agreed to donate Florian's code to OpenOffice!!!!!! Proving conclusively what i have been arguing for years: Sun does not allow for any changes to ODF unless and until those changes can be implemented by OpenOffice. The ODF Field Enhancements needed by Florian's fix to OpenOffice were originally proposed on July 12th, 2006, when Florian was the CTO of the OpenDocument Foundation. These changes to the way ODF implements fields were needed by the da Vinci plug-in as part of our efforts to save ODF in Massachusetts. so here we have a rather direct example of Sun refusing improvements to ODF when needed by another application (da Vinci), but supporting those exact same changes when it is OpenOffice that can be improved!!! The arguments that the OpenOffice.org Community isn't open also apply to the OASIS ODF TC work!!!!!!

Good catch by Eric!
This link is to the infamous Sun statement of support for MS OOXML issued by Jon Bosak when ISO DIS 2900 was voted on by the US delegation to ISO.
The statement is important because it directly references the core issue: MS OOXML was written for MSOffice and the billions of binary docuemnts bound to that application suite. ODF on the other hand was written to OpenOffice.
Because ODF was not designed for the conversion of those billions of MSOffice documents, conversion is next to impossible. The implementation of ODF in MSOffice is next to impossible. The loss of information, especially the presentation-layout information, is so severe as to be intolerable in the real world.
This leaves the real world, where MSOffice dominates over 550 million desktops, unable to implement ODF. In light of this real world problem, Sun's Bosak urges support for MS OOXML as an ISO standard!!!
So we have this situation at OASIS ODF where Sun is in control of both ODF and OpenOffice, refusing in all cases to compromise the linkage or accomodate the much needed interoperability enhancemnts seeking to improve the conversion of billions of documents to ODF. And publicly supporting MS OOXML as the only pragmatic alternative to the situation Sun is responsible for!

Heintzman must be referring to the Rob Weir -OASIS ODF Adoption (cough marketing-lobbying) TC event called the "ODF Interoperability Workshop". This was a day long event demonstrating for all the world to see that there is no such thing as ODF interoperability. The exchange of documents between OpenOffice 2.0, KOffice and Lotus Symphony is pathetic. The results of the day long event were so discouraging that Rob Weir took to threatening developers who attended in his efforts to keep a lid on it. I think this is called damage control :). From what i hear, it was a very long day for Rob. but that's no excuse for his threatening anyone who might publicly talk about these horrific interop problems. The public expects these problems to be fixed. But how can they be fixed if the issues can't be discussed publicly?

Lotus Symphony is based on the OpenOffice 1.1.4 code base that IBM ripped off back when OpenOffice was under dual license - SSSL and LGPL.