ODF: After all this time, I'm still just getting it

What has been said:

622.1. Nathan T. Freeman (09/06/2007 04:42 PM)

What you're leaving out is the part where Melissa reviews Mary's revisions and says "what!?! Were you on DRUGS!??!?"

The answer, of course, is that she was in a cafe. In Amsterdam.

:-)

622.2. Ben Langhinrichs (09/06/2007 04:47 PM)

True, there is always the people problem. On the other hand, Melissa CAN reject Mary's revisions before they get to the Notes database, which is a good thing given those Amsterdam Internet cafe's.

622.3. Darren (06/09/2007 20:58)

I'm just wondering why Mary isn't using webmail for her email rather than gmail?

622.4. Stephen (07/09/2007 04:23)

Keep going Ben ... eventually you'll understand why OpenXML should be a standard too ;-)

622.5. Ben Langhinrichs (09/07/2007 04:39 AM)

Stephen -

It is in some ways a perfect counterexample. Open XML is a total pain in the butt compared to ODF. If it were as easy to develop for Open XML, there would be more products which really support it, and my scenario might work for Open XML as it does for ODF. Right now, it doesn't. Gnumeric? Don't make me laugh. Does it support revision marking and document protection and modified results which are indistinguishable from Excel's? What's more, my scenario also points out just how nice it would be if MS Office also supported ODF, which is where the concept of a single standard to rally around makes sense. Imagine if some browsers worked with HTML, but not with Mythical Web Standard #2. Other browsers worked with Mythical Web Standard #2, but not with HTML. That would give the customers choice, right? Not! It would mean they had to keep switching browsers to see different websites, or not be able to see those websites at all. Maybe all broswers would eventually support both, but developing tools to work with websites would require twice the development, twice the Q&A.

Now do you see why Open XML should not be a standard? Or at least a strong argument for why there should be only one standard?

- Ben

622.6. Stephen (07/09/2007 08:46)

So I looked at your example. Are you saying that you can do this today with IS)26300:2006 ODF? Really? Gnumeric's support may be basic Ben but at least it allows for formula interoperability based on Ecma376.

Is your position that there should be only one standard?

622.7. Ben Langhinrichs (09/07/2007 09:29 AM)

Stephen -

I am not doing this with "IS)26300:2006 ODF" (update: OK, I am using ISO ODF, but I am not focusing on proving a standard, just focusing on using it), I am doing it with Lotus Spreadsheets (part of Notes 8), OpenOffice and Google Spreadsheets. They are all using different levels of ODF, I would imagine, but the interoperability is just great. And this isn't an argument about theoretical interoperability, it is about actual interoperability, as in it works right now. Does Gnumeric track revisions in such a way that Excel would recognize them? I don't know, but that is the question.

I am not sure about the question of "one standard". I think that it is great that Microsoft created an XML representation for their documents, although I think they did a lazy, sloppy job in many areas. I see no reason for it to become a standard, and I wish that ODF and Open XML and China's version were all merged in some way. Multiple standards for the same thing is just adding extra work. Enhancing ODF to fully support formulas is obviously a good thing, and a better idea than having competing standards. I don't want competing railway guages or lightbulb sockets, which don't add choice, they add annoyance, and office documents are similar. I think it is idiocy to act as if multiple choices for standards is equivalent to multiple choices for applications. I would rather see a plethora of applications that shared the ability to interact on the same data. We are closer to that with the Microsoft binary formats than with Open XML.

- Ben Langhinrichs

622.8. Nathan T. Freeman (09/07/2007 03:11 PM)

"Is your position that there should be only one standard?"

For only one purpose? Of course.

Stephen, do you advocate the use of hexagonal purple stop signs in some municipalities?

622.9. Nathan T. Freeman (09/07/2007 03:16 PM)

"It would mean they had to keep switching browsers to see different websites, or not be able to see those websites at all. Maybe all broswers would eventually support both, but developing tools to work with websites would require twice the development, twice the Q&A."

You mean like Navigator 4 and IE 3 did? That's pretty much the exact consequence in that era.

And you know what happened since then? Both platforms moved more to standards, and both were dramatically more successful.

(Oh, and in case Stephen wants to know, IE was a WAAAAAY better browser than Navigator was. That was back in the days when Microsoft actually did, y'know, engineering.)

622.10. Stephen (08/09/2007 03:49)

s/know/now

622.11. Ben Langhinrichs (09/08/2007 04:58 AM)

Stephen - Maybe I wasn't clear. My demo uses and recognizes ISO ODF. I assume the others do as well. My point was not that my demo was non-standard, but that I wasn't trying to prove standards compliance, just use it. The reason it works is because all of those products use ISO ODF and use it reasonably. Whether or not the standard is "robust enough" for your ideals, I don't know or care. So, to be perfectly clear, everything in this demo uses complete ISO standard ODF. Everything! Is that clear enough for you? I will revise my comment above just to be sure I don't confuse anybody.

622.12. Ben Langhinrichs (09/08/2007 05:21 AM)

Stephen - Your post that you link to on "Stuck in the past" doesn't allow comments, so I'll just address it here. Your vision of what Open XML should be is fine, but you have been betrayed by the people who designed the spec. I have tried it and tried ODF, and there is a huge difference. And I am not just mentioning these now. I identified (to Brian Jones among others) defects and issues with Open XML before it was an Ecma standard, and before it entered the fast track process. The specs are badly written and the editing was lazy, which explains some of the irritation with the specs, although obviously you are correct that some IBMers and others may have a vested interest in your failure. I do not have a vested interest, and in fact have a product that would be well served by being in implemented in both ODF and Open XML, but the spec is a mess.

Step back from blind idolatry of the Open XML specifications, and step back from a reflexive dismissal of every comment or complaint and take a look at the Open XML specifications. It is a mess, regardless of whether that is a matter of intentional obfuscation (as IBM and FOSS supporters seem to believe) or a matter of laziness and arrogance (as I believe). Despite Microsoft's attempts to circumvent the process, I think the comments garnered from this recent vote may be doing a huge favor to Microsoft. If the comments are listed to and responded to in a creative, thoughtful way, you may even come up with a spec that could become all the things you talk about so dreamily in your post. I would be glad, because I could then implement a reasonable OpenSesame product using Open XML, which would make my customers happy.

Try to remember, it is about the customers, and many of mine use Microsoft Office, probably way more than use any other office suite, so I would be thrilled to support their needs. I do not have all the hidden competitive desires to drive my dislike for Open XML, and I do not have any great affection for free open source software (you will notice that 0% of my software is either open source or free). If Microsoft had implemented Open XML as well as ODF was implemented, and by that I mean with a sense that people would want to actually build new applications using it, I would have backed Open XML as a standard. All suggestions that I and others made in that process were met with a completely blind dismissal and an insulting "You don't understand the need for backward compatibility", which was used to justify a total lack of open exchange of ideas. I was part of the Office 2007 and made these suggestions, so it was early enough that changes could have been incorporated in without as much pain, but Microsoft made its bed, and now has to sleep in it. I see little indication that Microsoft will do what it should, and I can only imagine the cost now that Office 2007 has been released to retrofit major changes, so I hold out little hope that Microsoft will go along with the changes to Open XML that it needs to to make a real standard. In that light, I oppose Open XML as a standard. Prove me wrong and do a great job in the revision process and I will happily join the Open XML parade, but don't just try to do a snow job. Do the hard work and it will pay off.

- Ben Langhinrichs

622.13. Oliver Bell (08/09/2007 08:48)

> I wish that ODF and Open XML and China's version were all merged in some way

I've been giving a lot of thought to that point recently, and I've pretty much come to the conclusion, looking at the specs for all three, that given the wide market adoption of all three in one form or another you would just end up with four formats rather than three if you headed down a harmonization route at this point.

If that really is a goal (and it is a laudable one) it is probably best that the existing three are driven through to the end of the ISO standardization process... then the library will contain all the information that you'd need to create that fourth standard that everybody seems to be so hungry for.

622.14. Stephen (08/09/2007 08:52)

angle brackets removed for 0.0001 read

table:table-cell table:style-name="4,3cel-Sheet1" table:formula="oooc:=[.$B$2]^[.B4]" office:value-type="float" office:value="0.0001"

text:p>0.0001 /text:p

622.15. Ben Langhinrichs (09/08/2007 09:07 AM)

Stephen -

I certainly conceed that it could happen, but in this case I have checked carefully, and none of the different applications leads to anything nonstandard. Every reference is correct, and while they different in very slight ways, they are all within the standard.

(Note: differences are things such as Lotus Spreadsheets adding lots of different styles for the rows and OpenOffice reusing more styles. Neither is wrong, but they do differ a bit.)

I understand where you are coming from, but this is not a case where anything nonstandard has to happen. It all just works. Could it break if we did more complex things? Likely it could, because as you point out, the formula part is underspecified so far. This is just a fully working example without any such problems, and there weren't even any changes I tried to put in but couldn't because of such issues. In fact, I wrote this entirely for Lotus Spreadsheets (and using the ODF specs because that is where everything is documented), and was pleasantly surprised to find out OpenOffice and Google Spreadsheets supported the demo. So far, ISO ODF is living up to its promise. I hope that Open XML can as well someday.

- Ben Langhinrichs

622.16. Ben Langhinrichs (09/08/2007 09:12 AM)

Oliver - You make a good point. It may well be that the time is past when merging the formats would work. I guess for the moment we will have to stick to improving the standards we have to accomodate proper translation from and to each format. I wish it could be otherwise, but we life in the real world, not the ideal world. - Ben

622.17. Jody Goldberg (09/08/2007 04:40 PM)

I maintain Gnumeric.

1) The entire example also holds true for the poorly documented binary formats in older versions of MS office. There is certainly better interoperability between just about any existing spreadsheet via xls than ods. kspread's historically poor support for xls is the only exception I can think of.

2) Gnumeric does not support revision tracking (yet) and hence does not support it via xlsx, xls, or ods.

3) I've implemented import and export in both ODF and OOX. While both formats have their strong suits and 'issues' it should be noted that the OOX filters were substantially easier to write, and are much further along.

ODF

- Prettier. There is less replication of similar concepts than in OOX. Although some of the shared concepts result in invalid state (eg applying WP style page breaks to a spreadsheet)

- Slower (for spreadsheets)

- Underspecified in many places. I couldn't even hazard a guess at how much needs to be added. The spec should probably double or triple in size at a minimum. That would just cover the current functionality. Supporting the full breadth of OOX will require extension to OO.o itself before the ODF elements could be considered.

OOX

- Inconsistent. Different pieces use vastly different styles.

- Careful thought had clearly gone into performance, and real world use.

- Specification could be slimmed down with better formating, but probably needs an extra 20-30% more material to make it clear enough to implement the majority of the feature set.

Both pay lip service to 3rd party usage, but could be substantially improved. I would have preferred both specs to simmer a bit more to get cleaned up before being frozen in standard land, but OOX easily surpasses the bar ODF cleared. If people are happy with ODF, they aught to support OOX too.

622.18. Ben Langhinrichs (09/08/2007 05:50 PM)

Jody -

First, let me say thanks for stopping by. I very much appreciate your perspective, and I would be very interested to hear more about the process. Does Gnumeric (or do you) have a blog or anything where you talk about the process? That would be a fascinating read. Unfortunately, most of my information is gleaned from either my own experience or from very technologically light pieces on Microsoft blogs, so hearing from someone who has gone further would be very useful.

As for the specific comments, a large part of the difference in our experience is that you are developing an actual spreadsheet, whereas I am developing a tool that mostly either creates from templates or manipulates existing XML in interesting ways. In that scenario, I barely touch the actual formulas, because except for certain search and replace type operations, I don't need to understand them, just to process them. In my case, this is a huge gain over the binary formats, because it is much, much easier to create either text or elements in an XML tree (I don't use a proper DOM, but my own XML tree for speed and ease of use).

ODF - This is much simpler for what I am doing, and there seems to be a very large overlap between the spreadsheet, presentation and document usage, which means I have lots of code that will work in all three with only minor variations. That is wonderful. Efficiency and performance of the resulting spreadsheet may eventually be an issue, but in most of my business scenarios, the real issue is performance of my code in processing, and that is extremely fast.

OOXML - One of the most annoying parts I found was the completely different models between the three parts, spreadsheet, presentation and document. It makes sense given the history and development of each, but it makes development of my sort of utility much harder. I imagine that is less of an issue for you since you are focused on the spreadsheet. Again, the performance considerations, especially for very large spreadsheets, are probably significant. It is clear that Microsoft has more real world experience with scaling in the spreadsheet area. Unfortunately, that makes little difference for my processing, except to hugely complicate the matter by connecting different parts of the spec in difficult ways, which does not happen much in ODF.

Anyway, thanks again, and perhaps I should tackle the Open XML again. I completely agree that I wish both specs had "simmered" a bit but we have what we have now.

- Ben Langhinrichs

622.19. Stephen (09/09/2007 03:46)

Ben I think we can all agree that everyone would have benefited if the market had been allowed to develop before rushing to standardisation.

Blame the European Commission's IDA unit for that - they pressed very hard for standardisation, despite being aware that ODF in particular wasn't ready, and despite a general acceptance that premature standardisation stifles innovation.

To return for a moment to the spreadsheet example, the OpenOffice namespaces aren't part of the ODF spec as I understand things. So your demo isn't using just ODF, it's using ODF plus "bits not in the standard that belong to Sun".

622.20. Ben Langhinrichs (09/09/2007 05:30 AM)

Stephen -

You need to get off your advocacy high horse and try to listen. I am not using any OpenOffice namespaces. You suggested the oooc: namespace yourself up above, but it never appears in my example. My OpenSesame product creates a spreadsheet which follows ISO ODF carefully. That spreadsheet is then modified by a series of applications, none of which add any namespaces, or anything much except revision markings about actual data that is passed around. I intentionally protect everything in the spreadsheet except the pure data values, since that is the point in this example, so they couldn't add anything if they wanted to.

So, my demo is using ODF, pure and simple, start to finish. I will not argue that there wouldn't be cases where I would use non-standard ODF, but that is like arguing that Office 2007 uses non-standard Open XML, which it clearly does (e.g., the VML use that is clearly deprecated in the spec). Other applications may need to do that - as of yet I have not in any of my examples. It is much like the C/C++ I write, which is intentionally not ever using platform specific code or libraries or compiler specific conventions, because I want it to be cross platform. OpenSesame intentionally uses very clean, generic ODF so that I won't get into such trouble.

So, no, I categorically deny using ODF plus "bits not in the standard that belong to Sun". I write using the ODF spec, and then test with Notes productivity editors and OpenOffice, because I happen to have two very good and separate applications using ODF right here. My daughter happens to use GMail, so I realized she could test with Google Spreadsheets, but it worked because I followed the standard, not because I followed the applications.

- Ben Langhinrichs

622.21. Stephen (10/09/2007 06:34)

Maybe I'm making too many assumptions Ben. My comments are prompted by what you're likely to get back from Google or OOo in your scenario more than what you send out.

But I hear you that when Melissa sends out the spreadsheet she creates using OpenSesame she sends out a file that you've carefully ensured only uses what's in the ISO ODF spec.

622.22. Rooks (10/30/2007 02:20 PM)

Stephen, if you work for MS, you need to stop where you are and realize that you will have differing opinions from others on this site, and you have no way of rationalizing MSOOXML to anyone that has seen through MS's issues regarding the format.

If you are not an MS employee, realize that you will have differing opinions from others on this site, and you have no way of rationalizing MSOOXML to anyone that has seen through MS's issues regarding the format. (copy/paste saves time.)

Ask yourself this: if you still complained if the roles were reversed and MSOOXML was the standard used, and ODF was trying to get ISO cert., then you probably have a valid argument. If not, then you have other interests forwarding your view that aren't related to standards or ease of use. If it were me and the latter example, I'd stop trying to antagonize people right now.

Stephen, no amount of dodging the issue will help MSOOXML, or any other format, for that matter. It really doesn't matter what formats you are talking about, the same rules apply. Brand X is bulky, hard to create, and doesn't really make sense to many people. And, it won't work with any other companies products except Brand X supported products (or ones that make deals with X). Brand Y is fairly lightweight, easy to use (easier than X, anyways) and ALL companies can use it for free. What about that doesn't make sense? Yes, it is a simplistic analogy and if you nit pick it, it won't hold up. That is not its purpose. The purpose is to say that "trolling" off a simple informative article about standards is kinda demeaning (to the troll) and displays the worst this industry has to offer in the way of communication.

Constructive feedback, such as "hey, I agree Ben, standards are a good thing. I would like to have all my documents work together w/o having to convert them regardless of which vendor supplies the software." is good. Destructive feedback, such as "hey, you are wrong, and you made this spelling error so your point isn't valid, and I don't agree with you because I can quote what you said and throw quips and remarks back at you that are more antagonistic than anything"... well, that's bad.

You don't even have to agree with the author (which you presumably don't) to be constructive, you could say something such as, "Hey, I don't agree that standards are good. I like my assortment of light bulbs. I like having to convert documents when I travel and have to use a computer that is not mine. I think that is the way to go!!!" See? Not antagonistic, constructive.

-Rooks