It’s time Microsoft decide how serious they are about real people using OOXML

February 16 2010

As many of my readers know, one of the areas that PSC has invested quite a bit of time in the past 24 months is around Document Generation. Document Generation is defined (by myself) as the ability to generate a document, based on a format, without having any software installed to generate or render the document. This can be done client or server side. I have done quite a bit of blogging on the topic - and taken both Microsoft and IBM to task. We have done some real world client projects, including the Research Director, Inc. project that was highlighted in this case study. While PSC does not participate in the ODF or OOXML standards process, I think our team is one of the deepest on the technical side. I have been working with the PSC team to get our technical knowledge out into the world to share our experiences and engage in the conversations.

The first piece of this engagement is a new blog called Coding the Document. Tim Murphy, a .NET guru in our Microsoft practice and one of the developers on the RDI project, is leading the charge in writing content. Tim and Andy Schwantes are the guys who have their hands deep into the XML side of these formats. They are the one's having to make my dream of Document Generation, which I present to our customers, come alive. They do amazing work and it is a honor to work with them.

So enter Tim's latest blog entries: The Challenges of Inconsistent Implementation and Office Document Generation, What Makes CustomXML More appealing Than Content Controls, & How Does Simple Text Markup Differ Across The Office 2007 Suite. Some background before I get into the rant ...

After completing the project highlighted in the case study for RDI, we began a second project. This project focused on building Microsoft Word documents dynamically. We needed to do more than content replacement in this project, actually bringing in new content sections and apply a common and consistent theme using templates. Tim and Andy came up with a great way to do this using the CustomXML functionality built into Word 2007. Why was CustomXML the right solution? Because we needed our customer to be able to edit the document AND we needed to be able to work with that content from the file format level. This is not the simple scenario that Microsoft uses with their demos: we are taking document parts, allowing a user to edit them many times, packaging them together, applying the consistent theme, and then allowing the user to edit the final document. CustomXML gave us the control we needed. Now, CustomXML sounds familiar to you probably ... that is because it is the core of the lawsuit that Microsoft lost that made them pull Microsoft Word 2007 from the shelves. I am not here to complain about the lawsuit - but the fact that the CustomXML functionality does not exist in Excel or PowerPoint! There is no way for us to take the process we have created and reproduce it in the sibling applications THAT COME IN THE SAME BOX! Microsoft suggest we use Content Controls. Those work in all three products ... until you look at the details! Content Controls are implemented differently in each application. Custom Control are also visible to the end user - we need something we can use that still allows a user to work with a document like normal. It seems the only solution we have today is to build our own Microsoft Office add-in, one for each product, that will give us the control and editing functionality we need. Those addins all will work differently on the implementation side of course. Ugh.

Second, imagine having a web browser where you used < B > and < / B > to bold your text. Pretty normal right? Now, what if another browser required < Bold > and < / Bold >. And a third that required < BOLD > and < / BOLD >. That would never work. Now imagine all three browsers came from the same company - and you have the situation of how different text markup is across the different Office 2007 applications. Here is a snip of what Tim wrote:

Text color is handled in Word simply by applying a Color object to the run properties.  PowerPoint requires a SolidFill object and child SchemeColor and LuminanceModulation objects to get the same effect.

The differences in the way that text is bolded is very similar.  In Word the run is assigned a bold object, but PowerPoint it is a boolean attribute of the run properties.

It won't shock anyone that the Microsoft Office applications work different to their siblings. VBA has always worked a bit different between the applications. But at the file format level? Why is the XML different to bold text in Word vs PowerPoint? The whole point of the investment of the move to the OOXML format was to give us some standardization. There is no standardization - its just easier to go in and manipulate.

Now, I really don't care about the differences between the OOXML and ODF specifications. I care about implementing real world solutions for my customers. And having the simple things, like text formatting, have to be different is not how we create a better solution. ODF is much better here - text blocks in a presentation are the same as a text block in a document or the text inside a cell in a spreadsheet (and I mean from the API level - I know the implementation at the core is different - I don't care about that).

Microsoft needs to stop putting it's focus on how many standards boards they participate in and how many cool demos they can create and fix their consistency issues. I know it is too late for 2010, but this needs to get fixed in Office 15. Microsoft, please put all of your product people in a room and agree to a single way to do the core stuff. Build a single XML specification and then have each product team add their specific stuff on top. Have the other teams review - and bring in some customers and partners before you set the stuff in stone.

Microsoft - if you want customers to start using this stuff in a significant manner, it's time to get serious about this. Otherwise, people will just play around and do what they have always done - treat Office as a tool and build their applications on top of real enterprise platforms. Until you change your thought process, as well as your implementations, Microsoft Office will never be part of that platform way of thinking. And that makes the ability to rip out Office and put in Lotus Symphony or Google Docs or OpenOffice.org a far easier move. I am more than happy to work with Microsoft to make this happen - but they need to have the conversation at the top of the Office organization. This needs to become part of the Office team culture.

2 Responses to “It’s time Microsoft decide how serious they are about real people using OOXML”

  1. 1) Rob Weir says:

    Office is comprised of 3 different apps from 3 different teams, and absent any opposing force they will follow the dictum of "architecture follows organization" and diverge in the ways you observe. Painful for the user, but very predictable.

    I did a post on this a few years ago with some illustrative examples of OOXML and ODF markup showing the kinds of problems in this area:

    { Link }

    It is probably too late to fix this in the markup. The whole "billions of legacy documents" thing. But it should be possible for Microsoft to clean this up at the tooling level. There is no reason why their document processing API's cannot (at a sufficiently high level) paper over the syntactic differences.

  2. 2) Ben Langhinrichs says:

    It is sad to watch all this play out, but hardly unexpected. Microsoft was intent enough on "winning" the OOXML standardization, but they have shown very lackluster enthusiasm for making it more than a nominal standard.

Leave a Reply