a 'mooh' point

clearly an IBM drone

ODF 1.2 in ISO (PAS-submission)

The other day a document landed on my "desk" in the Danish Mirror committee to JTC1 SC34. It was the document ”EXPLANATORY REPORT - OASIS Submission of OpenDocument v1.2 to ISO/IEC JTC 1 [JTC1 N12033]”. In other words: ODF TC in OASIS has wished to elevate OASIS ODF 1.2 to an ISO-standard.

OASIS is a so-called "PAS Submitter" to ISO, which enables more or less direct elevation of existing standards to be an ISO-standard, but without any corresponding work on the standard itself in ISO. OASIS ODF TC has used this process for ODF 1.0 back in 2006.

So ODF will not be maintained in ISO - and agreement has been made that work itself developing and improving ODF will be exclusively done in OASIS ODF TC - with subsequent releases to ISO for approval ... what someone might refer to as "rubber-stamping".

For OOXML a different agreement was made during sumission/approval of OOXML - that being that work with OOXML takes place in ISO and this is where the standard is developed and improved. That being said, a substantial amount of work with OOXML takes place in ECMA and a large amount of our work in ISO originates from ECMA's TC45 - the group where OOXML was "born". ODF 1.2 was approved in OASIS in september 2011 (and publicized in early 2012), and now three years later it has landed on our desk in ISO.

I immediately wrote to Danish Standards and told them, that I suggest that Denmark votes "yes". Technically this is not a task for the mirror committee to SC34 since the vote is on JTC1-level, but the more I think about it, the more I doubt that I made the right suggestion to Danish Standards.

Because does it add any value for anybody to - three years after approval in OASIS - ask for an ISO approval? Is there any good reason to spend time on this in OASIS and in ISO? If the argument is that there are some (governmental) institutions that require an ISO-standard level to use it in their organisations/countries - what good is it to them to wait more than three years to submit it to ISO for approval?

Will you be my friend too?

The other day I noticed that the traffic on my blog had increased dramatically. I couldn’t really understand why (I have not written anything substantial in quite some time) – all I could see was that the majority of the visitors originated from Google. The search results were mainly “Jesper Lund Stocholm”, “Alex Brown” and “OOXML” … which told me just about nothing at all.

But then I noticed that a few of them also included the term “boycottnovell” and “techrights”. This lead me to check out the feed from #boycottboy’s website – and behold – I was actually mentioned in one of his defamatory articles.

The article is this: http://techrights.org/2010/09/11/sc34-is-still-a-farce/ .

The quotes start like this:

Weir is then met by opposition from Brown’s longtime right-winger, the ODF-hostile Jesper Lund Stocholm [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. He is a known Microsoft booster and Weir’s responses to him go like this:

I wonder if I shall refer to myself from now on as “Goose” or similar. Alex is clearly the Maverick here.

Now – and this is where I envy Rob – #boycottboyquotes a conversation I had with Rob (which I clearly won, btw :-) ) – but conveniently leaves out everything I wrote. It seems to me that Rob and #boycottboy live in some sort of symbiosis – each benefitting from on another. #Boycottboy clearly regards every little thing Rob writes to him as a “badge of honor” – regardless of the content itself. And Rob very much benefits from #boycottboys critique-less c/p of his comments/articles … with the infamous “#boycottboy reality distortion field” applied.

I wish I had a friend like that. I wish I had a friend that would blindly recite every syllable coming from my lips – without any sanity-check at all.

I totally get why #boycottboy needs Rob – but why IBM’s chief ODF Architect (elsewhere known as “ODF’s one-man-army”) needs someone like #boycottboy is beyond me.

And you know what the silver lining is here? I actually benefit greatly (and not only in a monetary sense) from being posted on #boycottboy’s site. The increased traffic from techrights.org keeps the fire burning and it is almost always a certainty that someone will write to me to invite me to speak on document formats at conference, potential customers or even political parties.

So please keep it up, you two – it helps me avoid the wife and kid going to bed hungry at night.

Final nail in the coffin for the "highlander approach"

On January 29th the Danish politicians finally got their acts together and did something about open document formats. After almost 3 years of debate and endless dragging of their feet - a consensus and agreement was finally made on that Friday.

The agreement made had this content:

For use in the public sector in Denmark, a document format can be used, if it is on the list of approved document formats. To get on the list, the document format must comply with these rules:

  • It has to be completely documented and be publicly available
  • It has to be implementable by anyone without financial-, political- and legal limitations on neither implementation nor utilization
  • It has to have been approved by an internationally recognised standardisation organisation, such as ISO, and standardised and maintained in an open forum with an transparent process.
  • It must be demonstrated that the standard can be implemented by everyone directly in its entirety on several platforms.

If you ask me, this list is pure rubbish. Apparently a deal was made on that Friday morning literally minutes before an open hearing in Parliament and this bears all signs of a job done in too much haste.

(of course, all this happened when I was away on family weekend, but as you can imagine the blog-sphere went crazy and twitter buzzed like a hive of bees with the gent's of "big blue" and "big red" taking swings at each other)

Devil in the details

The problem is that it is written all over it that this list will be taken very literally and we are going to continue to have to discuss stupid details with stupid people - instead of getting to work to start giving value to our customers.

The problems pertain to item 1) and item 4).

Item 1 is actually not that big of a deal, but it is an example of a requirement that cannot be verified. Because what does "completely documented mean"? Does it mean that a mere list of all elements and attributes is enough to give a "thumbs-up"? Does it mean that a single ocurrence of the phrase "... is application defined" provides automatic rejection? Now, I agree with the idea behind this, coz' shit has to be documented but this item should be removed or altered to provide real meaning.

And what about item 4) ?

Well the problem with this is that no document standard of today can be said to comply with this requirement - thereby making the list Ø. The only way a document format can be said to comply with this would be to have 2 independant applications, each claiming to be implementing the specification in "its entirety". And still we wouldn't be able to actually prove it. We would, at best, be able to show that with high likelyhood the applications do actually implement the specification "in its entirety".

Two to go ...

So that basically leaves us with two requirements. The only requirement we should think of adding would be "It has to be relevant in the market" ... ODA, anyone?

The silver lining

But do not fret - it is not all bad. No, because the agreement effectively puts the final nail in the coffin for the "there can be only one document format"-line of thought. The Danish parliament has has turned its back on any exclusivity with regards to document formats and has turned its focus to "open standards". This is no doubt a positive move, because now it doesn't make any sense any more to argue "which one is bigger (or, smaller)" or over who got to the playground first.

With this decision Denmark follows other countries like Norway, Belgium and Holland where the notion of "open standards" is also the center of thought - and who have also discarded the idea of "value can only come if we only have one document format". This is fantastic - and I applaud our politicians on making this decision - even though some of the details lacked consideration.

Smile

Microsoft Office 2010 Beta, ODF and leap-year-bug

Some time ago I did some tests of Excel in Microsoft Office 2010 (CTP). The test was around OOXML - but test of ODF-support was missing.

One of the things ODF is missing but is in OOXML is the leap-year-bug ... although most of propably don't miss it all that much. The leap-year-bug is the good ol' Lotus 1-2-3 bug that treated 1900 as a leap year. As a consequence of that, calculations based on dates in the range from January 1st 1900 and February 28th 1900 with dates after this period will be off with one day.

Since Microsoft Office supports (a subset of) ODF, I thought it'd be fun to look at how Excel 2010 handles the leap-year-bug.

The first thing to do is to show how the leap-year-bug is handled by Excel:

So adding a day to February 28th 1900 will result in the non-existing date February 29th 1900, and if you subtract the dates February 27th 1900 and March 2nd 1900 (you'd expect the a value of 3) you actually get a value of 4.

So what will happen if you save this spreadsheet in ODF-format and open it again in Excel? You might expect that - since it was round-tripped through a format not supporting the leap-year-bug, the calculations would now be correct.

... but you'd be wrong. The result is excatly the same:

As I was, you might be wondering how the hell that was possible. But a simple inspection of the markup generated by Microsoft Excel 2010 reveals the answer:

[code:xml]<table:table-cell

  office:value-type="date"

  office:date-value="1900-02-29T00:00:00"

  table:formula="msoxl:=A2+1"

  >
  <text:p>29-02-1900</text:p>

  </table:table-cell>[/code]

A quick-and-dirty conclusion to this would be that Microsoft Excel 2010 violates not only ODF but also xsd:datetime, since February 29th is not a valid xsd:datetime. However, an inspection of ODF reveals that this is not the case. Microsoft Office claims conformance to ODF 1.1. and ODF 1.1 states the following about the value-space of the attribute "office:date-value" (Section 16.1 , p 702) :

A dateOrDateTime value is essentially an [xmlschema-2] date and time value with an optional time component. In other words, it may contain either a date, or a date and time value.

So strictly (*giggle*) speaking, Microsoft Office 2010 does not violate ODF 1.1 .

However - specifying an invalid date in an attribute that might contain xsd:dates is not very smart, dear Microsoft. Those of us wanting to use standard libraries to process the content of an ODF-document will likely get unpredictable results when trying to parse this invalid date. Heck, even .Net's DateTime.Parse()-method throws an exception when trying to parse this value.

Also, ODF TC has tightened up the prose in ODF 1.2 and it is now:

A dateOrDateTime value is either an [xmlschema-2] date value or an [xmlschema-2] dateTime value.

So Microsoft Office 2010 might not violate it now - but it will when ODF 1.2 comes out.

Extending ODF

Microsoft could always opt for extending ODF using the extension mechanism (to add elements and attributes using a foreign namespace). So Microsoft could chose to add their own attribute to the <office:spreadsheet>-element saying something like

[code:xml]<office:spreadsheet mso:EnableLeapYear="true"/>[/code]

The problem with this approach is that is comes into conflict with the new conformance clauses of ODF where a clear distinction between "normal" documents and "extended" documents is made. Procurement-wise it is a big no-no only to support extended documents (look what happened in Denmark!) and Microsoft risks that some government somewhere decides not to use Microsoft Office due to lack of conformance to the "normal" conformance clause of ODF 1.2.

Thus, Microsoft needs to find another solution ...

Configuration to the rescue!

Luckily for Microsoft (and we all know how picky they are wrt "preserving functionality" etc), there is a fully compliant way out of this while still preserving the leap-year-bug in spreadsheets - regardless of persistance format.

As you probably know that so-called config-item-sets are a gold-mine of endless possibilities. Originally (until ODF 1.1) the purpose of these elements and attributes were to store application specific settings, like (and this is a quote from ODF 1.1) "document settings, for example a default printer or view settings, for example zoom level". In ODF 1.2, all bets are off and there are no restrictions to the usage of the elements. The config-item-set elements were never meant to be an extension mechanism (by ODF TC co-chair from Sun/ORACLE - go figure), but OpenOffice.org uses them extensively - in fact, when creating a "blank" text-document, spreadsheet or presentation in OpenOffice.org, a total of 228 (76 for text documents, 66 for spreadsheets and 86 for presentations) settings (of which non are described in ODF) are defined in the the settings.xml-file of the packages. Somehow ODF TC has not found it necessary to include usage of config-item-sets in the "extended conformance clause", so a document can claim 100% conformance to ODF 1.2 "normal documents" while throwing dozens of settings into config-item-set elements. So the solution to claim conformance to ODF while enabling the leap-year-bug is simply

[code:xml]<config:config-item-set  config:name="mso:spreadsheet-settings">
  <config:config-item

    config:name="EnableLeapYearBug"

    config:type="boolean"

  >

    true

  </config:config-item>
</config:config-item-set>[/code]

This should be combined with this markup for the specific cell

[code:xml]<table:table-cell

  office:value-type="float"

  office:-value="60"

  table:formula="msoxl:=A2+1"

  >
  <!--<text:p>29-02-1900</text:p>-->

  </table:table-cell>[/code]

(and you don't really need the bit I have commented out).

I don't know about you, but I find this just darn right fantastic!

Smile

Danish Competition Authority suggests: Use ODF in public sector!

Get the information straight from the horse's mouth from DCA website. If you are not speaking Danish, Google will do a rough translation for you.

I'll update this article shortly ...

... oh ... and I almost forgot ... they suggested using OOXML as well.

Smile

Norway mandates PDF and ODF as exchange-formats

Norway has mandated use of PDF and/or ODF as document exchange formats. The baseline reference list of approved standards and formats has been released in a "version 2.0"-edition where, amongst other things, ODF has been approved in edition 1.1. An abstract of the text is

3.2.2 Dokumentstandarder for utveksling ved e-postvedlegg

Ved utveksling av dokumenter som vedlegg i e-post fra offentlig sektor til omverdenen (innbyggere og næringsliv), skal følgende standarder benyttes: PDF 1.4 – 1.6, PDF 1.7 (ISO 32000-1) eller PDF/A (ISO 19005-1) er obligatorisk format ved utveksling av dokumenter beregnet for lesing. ODF 1.1 (Oasis Standard 1. februar 2007) er obligatorisk og skal benyttes ved utveksling av dokumenter beregnet for redigering hos mottaker etter avsending fra offentlig myndighet. På grunn av begrenset utbredelse anbefales det midlertidig å legge ved ett eller flere tilleggsformater for å sikre allmenn tilgjengelighet. I slike tilfeller skal det tydelig informeres i e-posten om at vedleggene består av samme dokument gjort tilgjengelig i flere format.

Det er viktig å være oppmerksom på at publisering av dokumenter på nyere versjoner av PDF, kan føre til at en leser med støtte for en eldre versjon ikke kan lese hele dokumentet.

Ved mottak av ferdigstilte dokumenter i e-post fra innbyggere/ næringsliv, bør offentlig sektor som et minimum kunne håndtere følgende standarder: PDF, alle versjoner PNG (Portable Network Graphics, ISO/ IEC 15948:2003) JPEG (Joint Photographic Experts Group, ISO/IEC 10918-1) ODF, alle versjoner

For både ferdigstilte dokumenter og dokumenter for videre bearbeiding bør offentlig sektor også kunne motta alle andre formater med stor utbredelse innenfor anvendelsesområdet, som ikke gir den offentlige myndighet en urimelig stor konverteringsbyrde. Hvilke formater som konkret kan forventes vil være forskjellig innenfor sektorer og vil endre seg over tid.

Dokumentformatet OOXML ble publisert av ISO 18. november 2008. Den er besluttet fortsatt å være under observasjon.

I think this is great news for ODF that governments around the world are upgrading their procurement requirements to take advantage of the latest edition of ODF.

My translation of (parts of) the above is:

When exchanging documents as attachments in email from the public sector to users (citizens and corporations) the following standards must be used: PDF 1.4-1.6 (ISO-32000-1) or PFD/A (ISO 19005-1) are mandatory and must be used when exchanging documents designed for reading (only, ed). ODF 1.1 (OASIS Standard 1. February 2007) is mandatory and must be used when exchanging documents for editing purposes. Due to the limited market penetration (of ODF, ed), it is however recommended (temporarily) to attach additional document formats when sending data from a public institution.

(...)

OOXML was made public by ISO on November 18th 2008. It still under observation.

Smile

Is "interoperability" a transitive characteristic?

Way back when I was a math-major at university, we were taught about "operations on sets". A set could simply be "the natural numbers", which could be defined as all positive integers including the number 0. An operation on this set could be addition of numbers, multiplication of numbers and so forth. An operation can have a lot of characteristics, e.g "commutative", "associative" or "transitive". An "associative" operator means that you can group the operands any way you want and a "commutative" operator means that you can change the order of the operands. Confused? Well, it's not that complex when you think of it. The mathematical operator "addition" is an "associative" operator (or "relation") since (1+2) + 3 = 6 and 1 + (2+3) = 6. The operator "divide" is not associative since (1/2) / 3 = 1/6 whereas 1 / (2/3) = 3/2. Addition is also a commutative property since you can change the order of the numbers being added together. This is evident since 1+2+3 = 6 and 3+2+1 = 6. Similarly "subtraction" is not a commutative operator since 1-2-3 = -4 whereas 3-2-1 = 0.

The transitive characteristic is a bit different than this and the "everyday equivilant" would be when we infer something. So think of transitivity is a mathematical formulation of what we do when we infer.

The relation "is greater than" is a transitive characteristic - as well as "is equal to". Basically, a relation (is greater than) being transitive means, that if A > B and B > C then A > C.

The latter popped into my mind the other day when I was pondering over interoperability between implementations of document formats.

Ever since Rob's ingenious article "Update on OpenOffice.org Calc ODF interoperability", I haven't been able to get it out of my head.

 

1  /  2  / 3   

OASIS to JTC1: Bye, bye ...

Ever since the hoola about OOXML-approval there has been quite some discontent in the ISO community regarding how ODF TC has fulfilled its obligations after IS26300 approval. A few meetings have taken place to "amend the harsh feelings" and now some preliminary results have been sent to the NBs for consideration. For those with ISO privileges the documents [1], [2] can be found in the SC34 document repository.

There has been a lot of debate as to where maintenance of ODF should take place, be it in OASIS via ODF TC or via some construction as with OOXML, where the originating TC is included (assimilated) into SC34 and maintenance and development takes place there. I really don't care where these activities take place. I just want the best qualified people to do it.

Now, the documents deal with a definition of principles and a more specific definition of "who takes care of what?"-items. When reading through the documents, I couldn't help getting the feeling that what OASIS was essentially telling JTC1 was "It's my way or the highway".

JTC1 and OASIS have come to the following agreement around maintenance: 

  • OASIS ODF TC takes care of maintenance and development of ODF. 
  • National body participation in this work is encouraged to take place in ODF TC by either direct membership, via the "Comment mail list" or via TC Liaison (I didn't know JTC1/SC34 had one of those in ODF TC)
  • OASIS will submit each approved edition of ODF to JTC1/S34 for approval to make sure that approved standards are equivilant.

I completely agree on item 1) and 3) above, but item 2)? In the paper there is not a single sentence on how the procedures in JTC1 fit into all this. Why are there no wording regarding voting procedures in SC34? If ODF TC comes up with something new and "substantially different", it should be submitted using the "PAS submitter status" of OASIS (similar to the Fast track procedure ECMA used with OOXML). But a PAS submission requires voting in SC34 and if the vote fails (or substantial concern is raised), a BRM is scheduled. If the comments are fixed, the result of the BRM will be an "errata-sheet" and a new vote takes place.

Suppose the post-BRM vote approves the submitted ODF edition

  • what will OASIS do with the errata-sheet?
  • what are the principles for getting them back into the OASIS-approved edition of ODF?
  • what is the time frame?

Is the truth really, that OASIS doesn’t want JTC1/SC34 to do anything to ODF but rubber-stamp it when it comes our way?

When the original ODF 1.0 was submitted to JTC1, a maintenance plan was agreed upon. It had two small but really important words in it: "as is". The maintenance agreement said (AFAIR) that JTC1/SC34 was expected to approve future editions of ODF "as is". In other words, what OASIS managed to get JTC1 to agree to was essentially: "Don't look at it, don’t' open it, don't flip through it, just - don't touch it. Get a hold of the ISO-approval stamp, stamp it and send it back to us".

The only possible conclusion is that OASIS does not want any direct ISO-involvement in development of ODF.

That is fine - the ODF TC should do what they find best. But I am wondering if that also means, that OASIS will not send future editions of ODF to JTC1 for approval? Surely, OASIS can't live with the reputation of having their standards simply rubber-stamped by ISO? 

You may also ask why it is not good enough for JTC1-members to contribute to ODF through ISO. Well, OASIS is a vendor-consortium and the interests of the vendors seem to be somewhat different than the interests of the national bodies. If you look at the contributions of Murata Makato and Alex Brown through the ODF Comment list, it is clear that their interests in quality in schemas, constructs and the specification itself was not prioritized in the TC at all. To me a mix of vendor interests and national bodies is the best way to ensure high quality in any specification, but the proposed agreement between JTC1 and OASIS seems to cut out the national bodies acting as "national bodies"

I think it is a good idea to ISO-approve ODF in the future. But JTC1 needs to send a clear signal to OASIS saying, that is it fine that they want the “Seal of ISO” and we welcome them. But in order to have the cake, OASIS must eat it too. The ISO package must come with two items, 1) the ISO quality stamp and 2) national body involvement. You cannot just have the stamp! It should be emphasized that it is the prerogative of the national bodies to process the standards that come their way and that cutting them off and have them do nothing but rubber-stamping the specification is completely unacceptable.

The proposed maintenance proposal will be discussed at the JTC1/SC34 plenary in Prague on Friday, and I hope all national bodies have understood the ramifications of approving the maintenance agreement. I suggest the plenary responds by saying to JTC1/OASIS: "Thank you for your suggestion for a maintenance plan for ODF, but come back again when we as  national bodies have a solidly founded role in the maintenance of the specification".

Struck by the Wrath of Roy "Kahn" Schestowitz

As the real work of maintaining OOXML in ISO has begun, I have had some time to ponder over events throughout the last year - starting with the BRM in Geneva in February 2008.

Being in Geneva was really hard work, negotiating all day in a 120-seat plenum while in the evening preparing suggestions in coorporation with other delegates from other countries. It was fun, but hard, nevertheless. I remember sitting on my bed in the hotel room trying to sort out everything while trying to keep up with the debates happening outside our meeting room (a defecto radio silence had been initiated voluntarily by the more prominent bloggers around the world, so no information was being released to the people desperate for the slightest amount of information).

One of the tools I used was to keep track of the sites referring to my blog and one evening as I sat eating Swiss chocolate on my bed in the hotel, I noticed a new referral from Google Groups.

link

link

link

Microsoft Office 2007 - now with ODF-support

On October 22nd a long awaited email popped into my mailbox  - news of the release of first beta of Microsoft Office 2007 SP2. The reason for me longing to get my hands on this piece of software (and I have, in vain, tried to squize each and every single Microsoft employee I could to get it earlier) was not that it is a Service Pace for my current office application. Nor is it that I should now expect a more stable software package, because I am not troubled by instability in my everyday work with Microsoft Office.

My interest is caused by the fact that Microsoft Office 2007 SP2 includes support for ODF 1.1, and to be frank, it is not really because Microsoft has now chosen to support ODF natively in Microsoft Office - I am sure most would agree with me that they should have supported ODF a loooong time ago.

No, what will be interesting to see will be what it will mean for interoperability via ODF.

It's the standards, stupid

It has long been a public secret that you were walking in egg-shells when exchanging ODF-documents between ODF-supporting applications that are not somehow based/cloned from OpenOffice. Of course it is possible to exchange "BUI-documents" (yes, it is a acronym I have invented for this. It means Bold, Underline and Italics and represents rather simple documents without too much fancy pancy stuff in it.) but the best experience is when using OO spin-offs.

This makes perfect sense. When using the same program, you will get the least amount of problems. This is in essense the text-book/Page1 elevator pitch for Microsoft Office sales people

And this is exactly why ODF-support in Microsoft Office 2007 is interesting - it is the first major productivity application not based on OpenOffice that promises native ODF-support.

Now some people seem to think that as long as you use an open standard like ODF, PDF or OOXML, "interoperability" is somehow included. It is as if they are trying to apply some sort of Kant'ish "Das ding an sich"-thinking when they argue that achieved interoperability is somehow an intrinsic, guaranteed feature of an open standard. The funny thing is that every time I hear these arguments I always try (or fail, rather) to find a nice way of saying that they have understood squat of the problem and that they should try to work seriously with the subject at hand before speaking so bluntly about it.

The truth is of course somewhat different and this is why I genuinely applaud the work done with the OIIC in OASIS. The truth is that an open standard enables or facilitates good interoperability and that this potential is bigger for an open standard than for a closed standard. It is clear that both ODF and OOXML provide for better interoperability than the proprietary binary DOC-formats, but reversely the binary DOC-formats are also proof that fairly good interoperability is also possible when using non-open document formats. The world is not - once again - black/white, because it is clear that an open standard is not a requirement for interoperability - but it certainly helps a lot.

My point here is

Interoperability is not created by the standards. It is created in the applications based on the standard

All applications have bugs/quirks

This is the reason this is not about the standards - rather, it's about the applications. We are now in the situation that we have two big players supporting ODF (to a varying degree). But they will propably do it in different ways. We are now in a situation where we no longer have the luxury of the major ODF-producing/consuming applications being built on the same engine. My expectation is therefore that we will experience interoperability-problems with the ODF-applications, because Microsoft Office will likely do some things differently than the OpenOffice-clones (but comply to the ODF-spec at the same time).

This is why I asked Microsoft these two questions when I attented the first DII workshop in late July 2008 (they recently held another one but I did not attend).

1. How have you handled the possibility of using application specific settings in ODF?

As you know ODF has (and now also OOXML after BRM #¤"¤%¤#¤#&"#¤#"¤#¤%, thank you very much!) the so-called "config-item-set"-elements, which are used by the current ODF-implementations to store application specific behaviour. The problem with these elements and attributes is that they are not specified in the ODF spec, so there is really no obvious way to figure out what to do with the binary printer-blob that Lotus Symphony stores in ODF-documents produced by it. The short reply from Microsoft was: "We don't use it" and if you open the settings.xml-file in the ODF-package, it is empty. This is all fine and dandy - only problem is that you risk loosing information when exchanging documents.

2. How have you handled known bugs, features in other, major ODF-applications?

All applications have bugs - including ODF-supporting applications, so my question was perfectly legitimate. Again the answer was: "We don't handle it". With this answer Microsoft gets in line with alle the other application manufacturers that don't handle their competitor's bugs. There is e.g. a "bug" in KSpread's implementation of formulas (specifically the LOG-method). This is not handled by OpenOffice.org - even though it is fairly well known.The consequence is that strange things might happen when exchanging spreadsheets between KSpread and OOo Calc.

It didn't really matter before, 'cause not that many people use KSpread - but this picture is about to change with ODF-support in Microsoft Office 2007.

The bigger picture

I you will allow me to use one of my favorite, stupid expressions, then let's for a moment "step into the helicopter to see the bigger picture".

Because I believe that Microsoft's implementation of ODF will mean interoperability-problems using ODF-files in the short term. But I also think that it will mean better ODF-support on a broad scale - in the long run.

I have previously dealt with the MathML-support of OpenOffice.org which is slightly buggy. The ODF-spec says this about mathematical content:

Mathematical content is represented by MathML 2.0

And that's it.

As you might remember, the problems with OOo's MathML-support are due to the fact that OpenOffice.org requires a DOCTYPE-declaration in the MathML-object to display it. Also it seems that OOo will only display a certain kind of MathML. I have documented this in a previous post, but the short story here is that a simple mathematical equation in an ODF-document created using Microsoft Office 2007 SP2 will not display in OOo 3.0 nor Lotus Symphony 1.0 The ODF-file is perfectly valid and so is the MathML-fragment (tested using jing and the RelaxNG-schemas for ODF 1.1 and MathML as well as the MathML-tool from W3C, Amaya).

This example serves to illustrate my point: Microsoft's implementation of ODF will mean better support for ODF in the long run, because it forces existing problems in the applications to surface - and they can then be fixed.

And a small note for the trigger-happy ones: This is not due to the fact that Microsoft has implemented ODF - merely it is due to the fact that we will now have a new, major implementation of ODF to exchange documents with.

The problems described above have propably existed for years but no-one have noticed since most people use some kind of OpenOffice-clone for creation and display of ODF-documents. Now, on the other hand, errors in the applications (including in Microsoft Office) will be very obvious and the pressure to fix them will be much bigger. I also predict that Microsoft will have to speed up the release cycle of updates to their productivity-applications supporting ODF - at least when it comes to hotfixes of known problems. I don't think anyone will settle for bi-annual service packs for fixing trivial errors with big impact on productivity and interoperability.

Only remaining question now is: when will SP2 make it into Microsoft Office 2007? When it snows in Seattle?

(btw, I watched Grey's Anatomy yesterday, and according to them, it does snow in Seattle from time to time!)