Thanks for the response. Unfortunately, your blog does not allow comments, so I can’t respond to it fully without doing a new post, which seems rather overblown.

I’ll just mention a few points here:

Again, if people thought the ‘leap year bug’ was THE biggest criticism of OOXML, they certainly shouldn’t be allowed near spreadsheets. I covered that issue in my post. If this was such a huge issue for users, I guarantee you it would have been addressed by the spreadsheet application community, including Microsoft in the last couple of decades. It’s annoying, but not a whole lot more than that.

I think your idea of changing the namespace for transitional had some merit, however, the benefits for users and implementors of not completely breaking compatibility between document instances in a new version of ECMA376 outweighs this. Remember, there was an existing standard out there, just not an ISO one. ODF has the same heritage.

The mention of UTC in serial dates is a bug in the spec. This needs to be fixed. Serial dates have never used timezone information (even the “safe” UTC variant) and it is a nonsense to try and retrofit them in some way for that. If we want to make a leap forward in allowing spreadsheets to deal with timezones, that needs to be done using ISO8601 dates. UTC has advantages of not being affected adversely by DST changes, but then makes it difficult to know what the local time is, without other information being stored.

Your point 2 regarding a roadmap for Transitional is critically important and I would very much like to see you involved with WG4 – even if just on the phone conferences to help tackle that issue. You may or may not know that Alex Brown has been working on that issue for some time and we intend to discuss it at the Paris meeting.

I discuss point 3 above. In addition, if we were in a situation where there were only a handful of people creating and consuming these document instances, then a total break would have been justified. Breaking thousands of applications is not. We must be mindful of the costs that have to be borne by customers and implementors as well.

Point 5 is a question of interpretation, which is what we want to avoid.

Gareth

“Jesper, if after 25 years in the industry I’ve learned one thing, it is not to make business or technical plans for a competing product based on what Microsoft says at conferences.”

The way I usually handle “promises” from Microsoft is that if it is clear to me, that whatever is in Microsoft’s best interest – they usually do what they say. If, however, it is not in Microsoft’s interest – I like to see the actual results before putting my hands in the air.

(and jumping back)

“Symphony 1.3 was already at feature freeze when Excel 2007 SP2 was released. ”
Ok – so what you are saying is, that with Symphony 1.4 you will load these formulas? That is really great news.

Oh … and speaking of “being outside” – I’m going to Paris for the WG4-meeting in December – probably being the only one with a CANON camera. Talk about feeling like the odd one out.

PS: Welcome to Europe.

As for the SUM function, you are correct that this may be accurately described in ISO/IEC 29500. But I also know that many other functions are not described accurately. In fact, as you should know, your defect report log in WG4 is tracking some (but not all) of the known errors in the spreadsheet formula definitions. If we coded to the OOXML standard our customers would not be happy with the incompatibility that would result.

“We do not support OOXML. We support the Office 2007 XML outputs. These are two different and incompatible things, as you know.”

Well, I was not aware that the formula description for =SUM(A1:B1) is different in IS29500 and “Microsoft Office 2007 XML”, but you presumably know better than I.

“Symphony 1.3 was already at feature freeze when Excel 2007 SP2 was released.”

Ok – that kind of sucks, but was the feature freeze active at the time of the first DII-workshop in July 2008? That was when Microsoft’s usage of OOXML formulas in ODF spreadsheets was made public.

“Obviously, we cannot anticipate all possible incompatibilities that Microsoft will introduce into their code. Typically we can only react.”

Yeah, it sucks being on the outside )

“Have you seen a list of what Microsoft will be doing with ODF in Office 2010? It would be interesting to see whether the situation is the same, or if it is improved.”

No, I haven’t seen that. I have been busy being as much a pain in the ass as possible wrt Microsoft and the … ahem … not-clever moves they continue to make with Excel2010 (blog post coming up in a few days). I have tried to get some info on ODF-support, but getting that kind of information out of Redmond is like trying to squeeze water out of a rock.

My anticipation: no change what so ever (

/Jesper

Symphony 1.3 was already at feature freeze when Excel 2007 SP2 was released. Obviously, we cannot anticipate all possible incompatibilities that Microsoft will introduce into their code. Typically we can only react. Symphony 1.3 was compatible with the Microsoft/CleverAge Plugin for Office, which was the ODF support recommended by Microsoft at the time Symphony 1.3 was being developed. We certainly did not imagine that Microsoft would introduce changes to their formulas that would not only break compatibility with Symphony and OpenOffice (and KOffice and Google Docs), but even with their own previously recommended ODF solution.

Have you seen a list of what Microsoft will be doing with ODF in Office 2010? It would be interesting to see whether the situation is the same, or if it is improved.

“What is the reason why Excel is not able to do with OOXML what it already does with ODF?”

It’s an interesting question, coz not all things make sense.

Take Lotus Symphony 1.3 as an example. When creating a spreadsheet with e.g. Excel2007 with a formula in it, the import filters of Lotus Symphony imports it just fine and converts the formula to OpenOffice.org formulas. However, when Lotus Symphony encounters the exact same formula in an ODF spreadsheet, Lotus Symphony fails to load it.

I realize that you have dodged the question the last 2 or 3 times I have asked you this, but you being an “IBM guy” and all, can you explain why Lotus Symphony is not able to do with ODF what it already does with OOXML?

This post was mentioned on Twitter by dmahugh: Excellent summary of why serial dates are in ISO/IEC 29500, from @aristippus303. http://tinyurl.com/yhm2ue2...

I certainly understand the fact that the underlying storage format of dates in ODF is xsd:date. I was referring to OpenFormula in isolation really, as regards the usage of serial dates.

In addition, I was referring to Transitional, not Strict IS29500. In 29500 Strict, ISO 8601 dates are the only allowable representation.

There is no issue with existing ECMA376-1 applications having the data loss issue with Strict, since the namespace has changed, so the instances would not be processable by existing apps. This is not the case with Transitional.

Your point about Excel 2007 SP2 highlights the issue perfectly. Try and do the same with the RTM – it doesn’t work, because ODF functionality wasn’t implemented at that point in time. Just as an unpatched Excel 2007 or a Monarch 9 can’t deal with ISO8601 dates safely in a 29500 Transitional document, since that functionality did not exist.

I am not trying to say ODF has a “serial date problem” by any stretch of the imagination, just that there is nothing intrinsically evil about serial dates, in fact they are the right tool for the job here and the existence of them in OpenFormula helps to prove that point.

Gareth