OOXML - What Microsoft should be doing going forward

May 26 2009

So I have taken ODF to task in the past couple of weeks, and since I have stated that my position is to work with both ODF and OOXML, I thought it was time for a bit of tough love for Microsoft. Before I do that, a bit of a current state observation.

When someone says OOXML today, they can mean many things. For most, they are not talking about ECMA-376 or IS29500, the specifically mean Office 2007 file formats for Word, Excel, and PowerPoint. We can argue what the technical term used by the standards community uses, but let's get real. The average person has no clue what either standard is or what they are called or how they are different. They need to work with Office 2007 file formats - reading them and saving changes back to them. If you look at other software vendors; Apple, Google, IBM, etc; when they add OOXML support, they always call it 'adding Office 2007 file format' - and frankly, nothing has really changed for them since adding Office 2003 support. Sure, they might have better documentation than the old binary formats. The engineers probably like working with XML vs the old formats. But they aren't implementing based on standards. They are implementing based on what opens and saves in the editors themselves.

So here are some thoughts for Microsoft:

1. Get IS29500 Supported by vendors, starting with yourself.

I have been vocal that I was against the Microsoft decision not to go back and add IS29500 support to Office 2007. I think this was a big mistake - both technically and culturally. Microsoft has to lead in support of the OOXML format adoption - and this would make some folks more comfortable in Microsoft's involvement in the standards process. While we do not know what will be in Office 2010 / 14 officially, I am pretty sure IS29500 support is targeted. If Microsoft wants to see standard support for it's file formats move beyond the version support based on the editors, it needs to evangelize. It needs to work with vendors to implement based on the standard and specification. It needs to lead and get info out there. A minimum of 6 months before the release of the software - it should have a whole section on MSDN, along with the Channel 9 videos and training and workshops and all that, for anyone who wants to implement read and write support for the formats. If Office 2010 is coming out early next year, that time for this is NOW.

2. Start supporting the Application Automation community

I have stated this before, but the largest number of developers who work with Office automation today, outside of software ISV's who implement file format support in their software, are not C# developers. They are writing code in VBA inside Office or using Visual Basic. They might be using Visual Studio Tools for Office to move that code outside of the Office applications, but they are not hard core developers. These are not the C# or Java developers that OpenXMLDeveloper.org are targeting with the current samples available. These folks are the consultants or business analysts who are out in the world every day doing automation. The idea of moving to document generation sounds appealing, but the learning curve is too steep. Microsoft should really spend time on this base and build samples and resources for this group.

3. Add OOXML Libraries to VSTO / Visual Studio

One of the things that would really help the community of developers who are ready to move to document generation are built in libraries within Visual Studio. I am not sure if this goes into the core VS.NET or as a part of VSTO, but they should be in the box. Read to reference and start working with - and with lots of samples and documentation. I know the Open XML SDK is the beginning of this road, but here is the rub - Version 2 is not slated to be released until Office 2010 ships. I need something for Office 2007 and NOW. Waiting to release the Open XML SDK v2 is a very bad decision.

4. Start talking about plans for Access, Visio, Project, and OneNote

Now I know this will open a can of worms, but what I really want is a complete standard set for all of the Office applications. Yeah, I know, you can argue that Access doesn't need this - but being complete here would be nice. Project, Visio, and OneNote could do with standard formats that anyone could generate - based on a specification that goes thru the standards process.

For me, I am a big fan of having both specifications and having the market make both move forward in a timely fashion. Personally, things are moving too slow for me on both the ODF and OOXML fronts. My patience, or lack of it, is a well known issues. So outside of that, these are things Microsoft could fix this summer and make some major headway. And technically, most of this applies to ODF as well - just harder to pick on a single company with ODF :-)