OpenOffice is NOT a reference implementation of ODF 1.1. OpenOffice implements features that are not even specified in ODF 1.1 (for example: formulas). It cannot be a reference implementation of something that simply does not exist. ODF 1.2 should hopefully address this, but they will need to improve the language in the spec to make it less vague. Specifications are supposed to be specific (funny that).

So what you're saying is Microsoft shouldn't follow the standard?

And further to that, are you suggesting that all it takes is to look at a few spreadsheets and reverse engineer them. How many would they have to look at to get all the scenarios? 100? 1000? 10,000? Somehow I don't think that's an option unless all you want to do is sums.

Best comment on this article. You've nailed it exactly.

Because the format hasn't been finalised as a standard. How are you supposed to conform to a standard that isn't final? Once it's final, then you can conform, until then you can conform to what you think the standard might be.

If there is no definition in the spec, then a "reference implementation" cannot exist. The reference implementation follows on from the spec. Anything you do that isn't in the spec is called guesswork.

If you had to reverse engineer it from the OpenOffice implementation, myy guess is that Microsoft is rightly worried about code taint from it's developers reading open source code.

Second, they didn't comply with the letter of the spec, both failing to implement it properly and going out of their way to not implement features they already had working code for and ignoring both reference implementations.

That's the problem - the spec is too vague to be implemented properly. Because the spec doesn't spell things out in a specific way, it's impossible to implement in a consistent way - it's open to interpretation. The problem isn't Microsoft, the problem is the spec. ODF 1.2 should fix this.

Oooh, this is by far my favorite, that's why I saved it for last. If you're to the point where you're seriously considering disabling solitaire, this reveals a number of things about the organization:

1) The I.T. staff and/or managers are unapologetic control freaks and perhaps even proud of it.
2) You don't trust your employees to actually be productive on their own.
3) Your hiring standards are probably pretty low.
4) You have unrealistic expectations of employee efficiency.
5) Morale must really be in the toilet already.
6) It's solitaire for fuck's sake, possibly the most boring game ever devised. If your employees are playing it instead of whatever they should be doing, that means they have no motivation to work, which means management should be the ones to get their lunchtime games taken away, not the employees.

So what if it was an application that carried malware that you were blocking? Solitaire is a particularly silly example, but is representative of any application. It doesn't take much imagination to come up with an application that you might legitimately want to block. But you seem to be having such a good time, don't let me stop you...

Unfortunately few people in the *nix world seem to grasp that LDAP is just a protocol (that's the P bit of the acronym). It's just a standard way of accessing directories - which is what Active Directory is (as is OpenLDAP etc etc). LDAP means nothing as a reference to a directory - OpenLDAP might in your case. So what you meant to say was "directories (that are accessible via LDAP) have been around for years". Whether they do everything the particular implemention of Active Directory does is up for question - some may, some may not. It depends on implementation...

Ever wonder how all these other people can get it working, and you can't? Every thought it might not be the technology, it might be you? Just asking...

In Windows you need 1, one, uno, system image. Multiple user directories, and a DHCP server (plus Active Directory) and everything will work just like it is supposed to. Of course you need to change your way of thinking to accept this possibility.

You need one, that's right, one, system image that is either replicated and maintained on all the systems or is used to netboot the clients. The image contains all the companies approved and installed applications. This is a HUGE benefit to the IT department as they only have to test and deploy one image at a time.
That is great 1990's thinking there. Times have changed, and smart Windows admins are changing with it. What we do now in the Windows world is a thin image (base OS, Antivirus, Office probably) that is deployed to the local hard disk, and then virtualise applications into their own separate environments, and deliver them dynamically based on the user group membership. This is a huge benefit to the IT department as they maintain an image that is stripped down, and they don't have to rebuild their image every time a patch for any one of the applications comes out. Applications just work, and the great news is that we don't worry about app to app conflicts, or whether an app will do something to the OS - they're all virtualised so they just can't. Realistically a "mega" image is more work, not less. I encourage my clients to get to a single thin image, and then apply applications dynamically on top.

Oh yeah, you want to deploy it with netboot (PXE)? Not a problem. We've been doing that for years as well.