...we’re now looking at 150 man years to do the job for a competitive PPA.
”In fact, not even Microsoft Office 2007 implements something which complies with the existing specification.“There is no source code available for reuse (Microsoft Office is purely closed-source and proprietary) and there is no proper reuse of existing standards (e.g. for dates) inside OOXML. Also remember that Microsoft admitted that it is not committed to sticking to its own specification (OOXML), which makes it a moving target. In fact, not even Microsoft Office 2007 implements something which complies with the existing specification. It's merely a derivative which ensures no compatibility through a 'golden' reference (a written document, spread across over 6,000 pages). There are serious patent issues to consider, but sadly enough, no-one seems to notice.
I fail to see why Gnumeric has very, very basic support for OOXML while ODF support (the ISO standard) does not have any support yet. That's just what I was told yesterday. Are non-standards given precedence over international and open standards, which are suddenly/temporarily worth neglecting? [Correction: ODF support is coming shortly. See comments below.] The following assessment seems unrealistic.
Among the many other topics discussed at Ontario LinuxFest was a completely objective comparison of Microsoft's OOXML document standard and OpenOffice.org's ODF document standard by Gnumeric maintainer Jody Goldberg, who has had to wade through both in depth. His summary is that OOXML is not the spawn of Satan, and ODF is not the epitome of perfection. Both have their strengths and weaknesses, and he sees no reason why we could not go forward with both standards in use.
Comments
Jody Goldberg
2007-11-27 04:03:03
Roy Schestowitz
2007-11-27 04:08:11
Jody
2007-11-27 13:15:44
Gnumeric 1.6.x (the previous stable release) has had ODF import for years. It was not superb, there have been significant improvements since then, but it was enough for content, styles, and basic charting. What it lacked was export. 1.8 improves ODF import, and adds basic export. It also adds MOOX import at a level similar to ODF, and export that is somewhat better than ODF.
The '150 year' number is unrealistic. The XLS filters in Gnumeric or OO.o provide a huge chunk of the functionality required to map MS data structures onto native content. Our MOOX filters represent days-weeks of part time work. I'd be generous and call it a month of evenings. ODF filters have taken longer because we need to write the mapping from scratch, and have larger differences from our feature set, requiring more complex translation.
For 2.0 I plan to have both filters at the level of our xls support. While it is not 100% (no more than OO.o is) it seems to be 'good enough' for most use cases. Having actually worked with (and on) both formats I'm going to trust my judgment here rather than some talking point.
Roy Schestowitz
2007-11-27 18:09:28
The figure about the complexity and time of implementation was actually estimated by more than just this one site (the one which is cited). Be aware that there are undocumented bits too (yes, I know that you claimed on Slashdot that there are no proprietary extensions, but I beg to differ).
Hefe
2007-11-27 18:59:13
Can you or anyone you've quoted who states "150 man-years" say the same? I doubt it.
Perhaps the "expert" that quotes 150 man-years is a poor programmer with little-to-no experience actually implementing a spec?
The funny thing about people who "beg to differ" with Jody is that when you compare credibility, it's like night and day. You have Jody who is a very competent programmer who has 10ish+ years experience developing Office software and has read/contributed to both ODF/MOOX and you have Joe "Expert" who has 0 years experience implementing specs, 0 experience writing software (nevermind Office software), and hasn't actually even bothered to read either spec, but instead relies on anonymous Slashdot comments for their "insight".
If it's not clear who actually has a clue, it's Jody.
Roy Schestowitz
2007-11-27 19:08:06
2234e534e4355t6546
2007-11-27 22:40:18
About topic that you don't understand you should try to remain silent. You're just an embarrassment for everyone who love Linux.
Note: comment has been flagged for arriving from a known, pseudonymous, nymshifting, abusive Internet troll
Jody
2007-11-28 01:05:31
2) Ahhh, at last a binary blob that makes sense. I keep hearing about them, but have yet to actually see any mentioned in the spec, or in the sample files. Rob Weir and by proxy you, are at least partially correct. The macro streams do actually exist. There are however several caveats.
a) The macro enabled formats are explicitly different formats than than stock OOXML, Moreover they are not the default formats.
b) The binary blobs are in exactly the same format as the old binary formats. Michael and I cracked it a few years back (see libgsf, or OO.o). We can read and write it.
This was raised in the TC as part of the review process. The explanation given was that the VBA engine was in deep freeze, pending a move to something else. It would certainly be good to get this fixed. It is of less utility than the rest of the content to anyone accept virus checkers given that it requires an MS Office api implementation to actually interpret (the same way OO.o macros require OO.o uno interfaces) but it should still be addressed.
The reality of it is much smaller than the ominous clouds of 'proprietary extension' suggest. It is more an indication of the weakness of the MS Office code base, than of evil intent.
Roy Schestowitz
2007-11-28 02:13:06
This is news to me. Could you please show me one complete implementation of Microsoft Office formats? The latest OpenOffice.org, for example, is not compatible with Microsoft Office. For that reason, I never touch office suites (a shame really) and stick to something open -- LaTeX.
Could I prevent my colleagues from sending these? This is OOXML we're talking about here. Is Microsoft hiding a parallel OOXML universe somewhere (like... say... 'OOS (OOXML on Steroids)')? If so, I do not want this thing approved by the ISO and the GNOME Foundation's involvement has already done a lot of damage (see recent press coverage).
In other words, Microsoft wishes to standardrise legacy from its "old binary formats". Wonderful.
I am absolutely stunned and unable to understand how you are willing to accept some of this and acknowledge that you hacked something which interprets binaries. With standardisation, you basically pass on the burden for other groups (say... Google Apps) to backward engineer binaries and reconstruct/mimic Microsoft APIs (never mind the patent implications of this)
So please reject it. Explain to people that OOXML has a binary 'umbilical cord'. As it stands, your feedback in Slashdot denies this. This is what I call Microsoft-serving FUD. Sorry.
Roy Schestowitz
2007-11-28 02:45:30
ODF vs OOX : Asking the wrong questions
Lot of answers there. To quote one
Another one: (sorry, I just can't help it and it's hard to leave some out)
Sam Hiser:
Lots more at:
http://holloway.co.nz/
See:
Microsoft and Open Standards
Can Other Vendors Implement Microsoft's Office Open XML?
15 August 2007
http://holloway.co.nz/can-other-vendors-implement-ooxml.html
I love this one by the way (it shows the type of people who must be patting on the Foundation's shoulder):
http://holloway.co.nz/sincerity-generator/
This source not an antagonist. It's someone who is truly trying to help us getting rid of OOXML/.doc because they are both proprietary. They can only be controlled ans mastered by a single abusive company that will carry on moving the goalposts for profit.
http://holloway.co.nz/docvert/
There is a lot of information in these pages: http://www.freesoftwaremagazine.com/articles/odf_ooxml_technical_white_paper?page=0%2C0
This page is also good: http://www.freesoftwaremagazine.com/articles/odf_ooxml_technical_white_paper?page=0%2C8
Jody Goldberg
2007-11-28 03:23:10
Roy Schestowitz
2007-11-28 03:41:48