Slashdot Mirror

I have taken the time and looked at both specs. I even found areas for improvement in ODF and have suggested them. Two are being folded into subsequent versions, though not as a result of my particular voice.

My conclusion back then? It's a travesty that any time is still wasted even discussing the MS format. The MS format is not only unimplementable technically, as others have also concluded seen in the link, being loaded with problem after problem and missing definition after definition. If that is not enough, there is a swarm of licensing and sw patent issues that are unlikely to ever be resolved in a positive manner. ODF in contrast has clearly benefited from a long and open development cycle.

Probably the best way to see for yourself, though, not to pore through the dozens of pages in the standard or through the 6000+ pages of MS vomit, but instead to simply look at the existing implementations. Even better, take a look at some of the ODF tools available and try a few of your own implementations.

This shows that neither OO.o nor K-Office handle ODF faithfully, nor are they compatible with each other.
http://develop.opendocumentfellowship.org/testsuit e/summary.html

Also, OO.o adds things to its files that are outside of the ODF spec. If MSO's files aren't true OOXML files, then OO.o's files aren't true ODF files either.

Same situation as many other standard formats, such as HTML. Different apps handle formats differently, and often not 100% faithful to the spec.

I know of people, myself included, who have been after Apple for years to support OpenDocument. (Yeah, it's been that long already.) As far as I can tell, the way their bugreporter is set up it's not possible to view other people's bugs. That means that all requests for supporting open standards get blown of as "duplicate" without being able to see the original or its status.

It'd be really interesting to know the real reasons Apple's still failing to support formats like OpenDocument and Ogg. Ogg entered the double digit marketshare two years back. OpenDocument is recommended by governments around the world for a few years as well. It can't be that M$ is threatening withholding its applications from the platform, because there aren't any left to speak of. Productivity software was the last piece, but faster, better, cheaper, more stable, more interoperable software can be had from everyone else -- again since a few years back. So, what's the hold up at Apple about open formats?

The first link google, yahoo and live bring up...

http://weblog.infoworld.com/realitycheck/archives/ 2007/05/odf_vs_openxml.html

Not so favourable to your argument. It basically says exactly the same thing I did, this is a battle between Microsoft and a bunch of companies competing against Microsoft for market dominance.

The second link on google...

http://opendocumentfellowship.org/introduction/odf _vs_oxml

Is of course more favourable to your argument. Yet it seems the best they can come up with is that OpenXML isn't well supported yet.

So no, OOo won't replace MSOffice quite yet

You're absolutely right. I agree 100%.
And that's exactly why governments entities and educational institutions in Texas, Massachusetts, Israel, India, Singapore, Germany, France, Brazil, China, Macedonia, Denmark, and from the opendocument fellowship *deep breath*. Australia, Austria, Belgium, British Columbia, Manitoba, Ontario, Croatia, Czech Republic, EU bodies, Hong Kong, Netherlands, Pakistan, Philippines, Poland, Portugal, Spain, Switzerland, Turkey, UK, and from the USA: Colorado, Florida, Georgia, Indiana, Maryland, Montana, Nebraska, Nevada and New York... are NOT all switching or planning to switch to OpenOffice.

Oh wait. They are!

Read:
http://old.opendocumentfellowship.org/Articles/Int roductionToTheFormatInternals
http://old.opendocumentfellowship.org/Articles/For matODFVsMSXML

And let me know if you still think the ODF is merely a 'memory dump in angle brackets'.
I have read and understood. I repent. It basically is XML with styling and if it's here already we're not going to get any better. Embedding ODF readers in browsers would be quicker and cleaner than further extending CSS all the way out to spreadsheets and what have you. Well ... here's hoping.

Dave

Read:
http://old.opendocumentfellowship.org/Articles/Int roductionToTheFormatInternals
http://old.opendocumentfellowship.org/Articles/For matODFVsMSXML

And let me know if you still think the ODF is merely a 'memory dump in angle brackets'.
I have read and understood. I repent. It basically is XML with styling and if it's here already we're not going to get any better. Embedding ODF readers in browsers would be quicker and cleaner than further extending CSS all the way out to spreadsheets and what have you. Well ... here's hoping.

Dave

Read:
http://old.opendocumentfellowship.org/Articles/Int roductionToTheFormatInternals
http://old.opendocumentfellowship.org/Articles/For matODFVsMSXML

And let me know if you still think the ODF is merely a 'memory dump in angle brackets'. Maybe they could have reused a good chunk of CSS, but that would also require another type of basic parser in implementations. I imagine you've heard of expat, but can you name a standard CSS parser library? I can't, and once upon a time, I had CVS checkin privs on mozilla. Looks simple enough, but ask a web developer if they've ever heard of any major browser having CSS parser bugs.

And it looks like ODF's style definitions could maybe be generously described as CSS in XML, too. Regardless, I think you could make a pretty compelling argument that the layout needs that have historically driven CSS are a little different than a word processor's needs.

Back when I worked on Abiword, the native format was very similar to XHTML/CSS. Some arbitrary element renamings -- I believe our equivalent to the span tag was a single letter. The XML->XHTML conversion could probably have been handled by a simple sed script.

For styling, we reused as much CSS as possible. I learned about a lot of nifty stuff in CSS3 back then. I hope I get to use some of that stuff in browsers some day. But we were well on our way to the first draft of a hypothetical CSS3 Wordprocessor Module, too.

The OOXML format does strike me as a brain dead C struct to XML encoder, however. And I know the doc format pretty well, having written some non-trivial bits of wvware and the Abiword importer based on it. We actually once got a post on the mailing list from someone looking for technical details on the doc format, and they had been forwarded to us by someone on the Word team at Microsoft. They had their time-tested, battle-worn libraries, but we apparently understood the actual bytes better than anyone still in Redmond willing to help a customer.

But we all knew that the eventual Microsoft XML format was going to be silly. Actually, it's better than I expected. I had considered the occasional base64 encoded binary data structure wrapped in data tag to be a very real possibility.

In my mind, the most astonishing thing is that they just arbitrarily reimplemented -- and generally very badly -- dozens of standards, including many ISO ones. I believe they have several novel timestamp definitions, in addition to ISO's.

I'm pretty shocked anyone is even pretending OOXML is being seriously considered as a standard. I think some people in Redmond had an April Fools' joke get out of hand. If this gets standardized, I expect the next anti-trust case is going to reveal internal Microsoft emails with text such as "holy shit, ISO just accepted our format!"

PS: I don't even read slashdot that often anymore, and I very rarely post. The few times I do, I generally don't even bother to login. But it would seem that several years of random hobbyist open-source contributions have made me quite likely one of the top few dozen or so domain experts on the planet regarding your specific post. I thought that was kind of amusing myself. I don't know if anyone actually cares, but my name is Justin Bradford, and I imagine google retains sufficient evidence of what I claim.

Read:
http://old.opendocumentfellowship.org/Articles/Int roductionToTheFormatInternals
http://old.opendocumentfellowship.org/Articles/For matODFVsMSXML

And let me know if you still think the ODF is merely a 'memory dump in angle brackets'. Maybe they could have reused a good chunk of CSS, but that would also require another type of basic parser in implementations. I imagine you've heard of expat, but can you name a standard CSS parser library? I can't, and once upon a time, I had CVS checkin privs on mozilla. Looks simple enough, but ask a web developer if they've ever heard of any major browser having CSS parser bugs.

And it looks like ODF's style definitions could maybe be generously described as CSS in XML, too. Regardless, I think you could make a pretty compelling argument that the layout needs that have historically driven CSS are a little different than a word processor's needs.

Back when I worked on Abiword, the native format was very similar to XHTML/CSS. Some arbitrary element renamings -- I believe our equivalent to the span tag was a single letter. The XML->XHTML conversion could probably have been handled by a simple sed script.

For styling, we reused as much CSS as possible. I learned about a lot of nifty stuff in CSS3 back then. I hope I get to use some of that stuff in browsers some day. But we were well on our way to the first draft of a hypothetical CSS3 Wordprocessor Module, too.

The OOXML format does strike me as a brain dead C struct to XML encoder, however. And I know the doc format pretty well, having written some non-trivial bits of wvware and the Abiword importer based on it. We actually once got a post on the mailing list from someone looking for technical details on the doc format, and they had been forwarded to us by someone on the Word team at Microsoft. They had their time-tested, battle-worn libraries, but we apparently understood the actual bytes better than anyone still in Redmond willing to help a customer.

But we all knew that the eventual Microsoft XML format was going to be silly. Actually, it's better than I expected. I had considered the occasional base64 encoded binary data structure wrapped in data tag to be a very real possibility.

In my mind, the most astonishing thing is that they just arbitrarily reimplemented -- and generally very badly -- dozens of standards, including many ISO ones. I believe they have several novel timestamp definitions, in addition to ISO's.

I'm pretty shocked anyone is even pretending OOXML is being seriously considered as a standard. I think some people in Redmond had an April Fools' joke get out of hand. If this gets standardized, I expect the next anti-trust case is going to reveal internal Microsoft emails with text such as "holy shit, ISO just accepted our format!"

PS: I don't even read slashdot that often anymore, and I very rarely post. The few times I do, I generally don't even bother to login. But it would seem that several years of random hobbyist open-source contributions have made me quite likely one of the top few dozen or so domain experts on the planet regarding your specific post. I thought that was kind of amusing myself. I don't know if anyone actually cares, but my name is Justin Bradford, and I imagine google retains sufficient evidence of what I claim.

Does anyon know if there's any such thing as a "corporate petition" that I could pesuade my company to join?

There was a petition, but it's largely over and the result of MS at least giving lip service to OpenDocument support has been achieved. It remains to be seen what really happens with the third party plug-ins for MS Office, which is what the support amounts to it may be unsupport. Though the MS sponsored plug-in is the only one that makes the news, the one that has actually entered testing is the OpenDocument Foundation's ODF Plugin for MS Office.

As far as petitions go, about the closest thing right now would be for your business to sign onto the OpenDocument Alliance.

You're stuck in that position because of the file format and wouldn't be in that position if

1. Third party tools had access to the complete file format specification so the actually could generate an 'excel document {sic}' with charts. That's not gonna happen with existing formats and the licensing questions about MOOX / DOCX suggest future replacement formats out of Redmond may not help out so much with that.
   
   ... or ...
   
   
2. There was a universal format that included spreadsheets (aka 'excel documents') and charts, etc.

The solution's been visible for a long time. It's only lately that it's been within grasp.

You mean, like OO.o already has?
OO.o has extended ODF for its own purposes since the ODF spec itself is incomplete (e.g. lack of a standard for storing spreadsheet formulas).

And how about this little gem?
http://opendocumentfellowship.org/applications/kof fice
"Our tests show that OpenOffice and KOffice have some problems opening each other's OpenDocument files. Also, support for drawings is a bit incomplete."

I wouldn't be surprised if MS ends up with better ODF support (i.e. more compliant to the spec, as opposed to just trying to mimic whatever OO.o does) than most ODF-native suites.

It looks like the OpenDocument Fellowship will have another application to add to its list.

If you're a developer, like myself, you may be wondering how you can take advantage of OpenDocument. Afterall, the point of it is not to have to have developing licenses or the inability to generate your own documents for applications that your user uses. Check out their site for developers. From there, you can find the resources to begin writing your own code that generates ODF compliant files. If Microsoft ever switches to ODF compliance, you might be ahead of the game!

It looks like the OpenDocument Fellowship will have another application to add to its list.

If you're a developer, like myself, you may be wondering how you can take advantage of OpenDocument. Afterall, the point of it is not to have to have developing licenses or the inability to generate your own documents for applications that your user uses. Check out their site for developers. From there, you can find the resources to begin writing your own code that generates ODF compliant files. If Microsoft ever switches to ODF compliance, you might be ahead of the game!

Wow, I hadn't realized (till reading more posts and your response) that this thing isn't available and hadn't even been talked about before that article. And, on further reading I'm beginning to wonder about this OpenDocument Fellowship.

Where is this "ODF plugin for Office" even listed on their activities page?

These guys are accepting donations to promote "openness" while their principles are off writing what appears to be proprietary software? That kind of turns my stomach. Even if this ODF plugin for Office were just vaporware, they're still baldly lieing to the community.

Either way my opinion of the OpenDocument Fellowship just dropped quite a few rungs.

Wow, I hadn't realized (till reading more posts and your response) that this thing isn't available and hadn't even been talked about before that article. And, on further reading I'm beginning to wonder about this OpenDocument Fellowship.

Where is this "ODF plugin for Office" even listed on their activities page?

These guys are accepting donations to promote "openness" while their principles are off writing what appears to be proprietary software? That kind of turns my stomach. Even if this ODF plugin for Office were just vaporware, they're still baldly lieing to the community.

Either way my opinion of the OpenDocument Fellowship just dropped quite a few rungs.

Actually, it's posted now:

OpenDocument Fellowship Software page has a link to the SourceForge OpenOffice filter to Microsoft Word XML plugin project.

As soon as Microsoft releases a fully documented, non-patented format, or at least creates a perpetual license for F/OSS projects to use a patented format, I'll welcome them with open arms.

They've promised to create exactly that perpetual license, and there's pretty much no question at this point that they will indeed do so. The problem is this: Their proposed format sucks, and ECMA probably won't do anything about it.

Compared to ODF, the format Microsoft is proposing is vastly less suitable for XMLT transforms. It fails to leverage preexisting standards, so other implementations can't take advantage of existing code to render and manipulate SVG, MathML and the like.

Please see the OpenDocument Fellowship's introduction to the technical merits of Microsoft's proposed format to better understand the extralegal objections to the same.

Please sign the petition at http://www.opendocumentfellowship.org/petition/. We are trying to demonstrate consumer demand for OpenDocument. Thanks.

The new OpenDocument Fellowship is working with a petition to get Microsoft to implement the format. SIGN IT! http://www.opendocumentfellowship.org/petition/