Oliver Bell’s weblog

There are no shortage of press and blog stories this morning sharing the news that Microsoft has committed to supporting version 1.1 of the Open Document Format in SP2 of Office 2007.

As the announcement happened while those of us here in Asia were sleeping peacefully pretty much everything that could have been said on the topic has already been said, so I thought it might be more useful to present more of a round up of what I’ve been reading this morning.

First of all a little about the announcement itself.

There is a lot more to this than just support for ODF in the Microsoft Office product, although obviously the native support for ODF is a focus for many of the words that have been written overnight.

The company also announced plans to offer greater support for a number of alternative document formats - including Open Document Format (ODF) v1.1, Adobe Portable Document Format (PDF) 1.5, PDF/A and XML Paper Specification (XPS) - within Word 2007, Excel 2007 and PowerPoint 2007.  

In addition, Microsoft will support the future maintenance and evolution of these format standards by participating on the standards committees charged with these activities. This means that Microsoft folks will join the OASIS ODF TC and participate alongside IBM, Sun, Novell and everybody else present.

Finally ODF will be added to the list of specifications that are covered by the Open Specification Promise, ensuring that every developer has access to any intellectual property that Microsoft might put forwards during these maintenance processes.

The Microsoft blogs that first carried the announcement were the usual folks.

Jason Matusow looks at this announcement in the context of the companies continuing commitment to interoperability as a tenant of the way we design products and collaborate with the rest of the industry. Jason and I share views on the issue of so called “single standards” and he eloquently explains that further in his post.

This is not about any one document format “winning” – it is about enabling customers to evaluate and use document formats that make the most sense for them. Just as the MS deal with JBOSS didn’t mean we were saying that J2 was better than .NET – it is that we want our customers to have the most positive experience possible when using our product.

Doug Mahugh talks about some of the more technical details of the announcement, as well as discussing what this means to existing initiatives. He talks about our continued commitment to the translator projects for ODF, DAISY, UOF etc. and links to the ODF Translator team blog where they have just kicked off version two of that project.

Finally Doug answers a question I was asked over dinner earlier this week… we’ll be adding APIs that allow third parties to intercept the ODF load and save paths so if anybody disagrees with our implementation then all the tools are available for them to write their own.

Gray Knowlton digs around the “Why?” question, again one that came up in my dinner conversation earler this week. Why now? Why when OpenXML just got approval? etc.

Success in our industry (like a lot of other industries) boils down to successfully addressing the needs of customers. By offering greater choice for file formats, our products address more scenarios and provide greater flexibility in enabling specific solutions. From a pragmatic standpoint, adding ODF to Office allows us to re-focus Office on product capabilities rather than a debate about file formats. We’re quite comfortable when we compete in the marketplace on these merits.

Looking around the blogosphere this morning the announcement appears to be very well received by just about everybody, as I said earlier in this post most people seem to be focused on the component of this announcement that talks about native ODF support in Microsoft Office, but it is important to recognize that this is bigger than just that one item.

The announcement, in my view, demonstrates a strong commitment to the Interoperability Principles that we shared earlier this year. As always there is still much work to be done, but this is a great step in the right direction.

If you want to read a little more then here are some links that you might find useful. There is a lot more out there, feel free to link anything addition that you find in the comments of this post.

Press: PC World NZ, Information Week, CNet News, SD Times, New York Times, itWire, Slashdot(!)

Blogs: Stephen McGibbon (MS), Jerry Fishenden (MS), Brian Jones (MS), Jesper Lund Stocholm, Richard Koman, Andy Updegrove, Bob Sutor, Ed Brill, GeekZone NZ, Joe Wilcox, Eric White (MS), Savio Rodrigues

On a final note, I feel compelled to pull one paragraph out of Bob Sutor’s (IBM) post;

There is no reason for more governments and organizations not to start mandating the use of ODF. If you are not using ODF today, you should put adoption plans in place.

There is an area where Microsoft and IBM seem to disagree.

My own personal view on this, which appears to be shared by a majority of the customers I work with, is that mandating a single standard for anything IT related is generally not a great move for government.

IT standards, like any area of technology, move on.

Governments need to remain ready to move with the technology that is in use by their citizens and businesses, mandates for information technology standards often do little more than operate as a hurdle to doing this.

You might remember some time ago Intergen released a test project to CodePlex that converted IIS logs to SpreadsheetML.

This week at MIX’08 in the United States they have done it again, this time releasing a Silverlight 2.0 based OpenXML WordprocessingML viewer.

The work has been done by a small team over the last couple of months, with James Newton-King leading the development work, James talks a little on his blog about what it has taken to build this.

The work is making the headlines both in the New Zealand press, and overseas.

Here is an extract from New Zealand’s Computerworld;

Kiwi software developer Intergen is launching software it claims is a world first at the MIX08 conference in Las Vegas this week.

The company’s TextGlow product allows users to view Word documents created in Microsoft’s controversial Office Open XML format without having to download them and without having Microsoft Office or Word installed on their computers.

[...cut...]

As one of the first applications to combine Office Open XML and Silverlight, TextGlow is a technological breakthrough. It works cross platform and is freely available to all users.

This is a really good example of a small team making use of the OpenXML specification to build a really cool tool!

You can take a look for yourself here.

Over the last twelve months I have met a number of developers who are working with the OpenXML specification to build a wide range of applications.

One of those developers is Jason Harrop, who has been working on a couple of projects using the spec. The first was a set of tools that allows users to simultaneously edit documents, using a plugin for Microsoft Office on one end of his applcation, and a set of Linux based backend tools to manage the communications.

His second project is a java based application that will allow users to work with OpenXML documents regardless of their choice of platform, he calls the project Docx4All. Additionally, all of Jason’s code for these two projects  is published under the GPL.

Docx4all is a WYSIWYG editor for docx files which runs on Vista, XP, and linux. Of course, it uses docx as its native file format. It is currently a proof of concept but the application already provides basic formatting and editing (including cut/paste, and styles) and so on.

Jason tells me the WordprocessingML in the docx file is unmarshalled directly into classes generated from the OOXML schemas, using plutext’s docx4j library. In principle this approach allows for 100% compatibility with with other existing office automation applications, since there is no conversion to another internal file format.

There doesn’t seem to be any table support in the current release, but there is basic support for printing, via PDF.

If you want to take a look for yourself then you can launch docx4all from your web browser by following this link. It will install locally, so you don’t have to be online to use it.

If you’re interested in taking a deeper look then a virtual appliance containing a full docx4all development environment is available from here. The appliance runs Ubuntu, a good example of OpenXML development and implementation taking place completely away from Microsoft’s stack.

If you cast your mind back just over a year or so you might remember this agreement that Microsoft announced with Intel and RosettaNet to develop the next generation of their supply chain standards around Ecma Open XML.

It turns out that RosettaNet do a lot of their development work in their labs in Malaysia, and we are starting to see fruits of their efforts appear in the market.

This week there have been several stories in the press in Malaysia about the development work that has been taking place, and this morning you will find a regional article on ZDNet Asia.

From the article;

“Having proven itself to be a successful standard with large enterprises and multinationals operating in Malaysia, RosettaNet is now moving into its next phase of encouraging local Small Medium Industries (SMIs) to automate their procurement processes,” Foong said.

“Open XML opens up exciting opportunities for RAE based solutions, such as its support for custom defined schemas which facilitates wider success of e-commerce, while assuring users of long-term preservation of data.

“Another benefit of Open XML for the SMI community is its capability of storing and managing business data in documents, resulting in lower costs for implementing business process automation that enhances global competitiveness,” Foong added.

Foong Heng Huo, is the director of RosettaNet Malaysia.

This work with RosettaNet very clearly demonstrates the value that the Ecma Open XML draft brings to implementation of business process systems, something that you just can’t do with “other” formats.

 Another very long post I’m afraid… I promise to try harder in future.

 A couple of days ago the comments on another post strayed into the area of custom schema support in the Ecma Open XML specification. In my reply I documented a scenario that explained how this functionality might be put to use by developers. This is a really exciting part of the Open XML functionality, so I thought it might be worthwhile pulling the comment out into a post in its own right… so here it is.

The scenario below looks at how the Open XML specification may be used in a medical environment, looking at how some data that starts off being input into a document may pass through a series of systems, both internal and some provided externally.

First of all forget about the file format as an office automation document for a moment, and think about it as a container for data in its raw form. The Ecma Open XML spec defines a way to embed custom schema into the document that can represent just about any data you like, then guarantee that it will remain intact as one application or another opens the document, works with it then saves it out.

Now bringing it back to being a document format again, Open XML allows you to bind elements from those custom schema back to properties in the document if you choose, so not only can the custom schema be manipulated by automated systems, but also by a user through a form in their office automation application.

If we apply that to our health-care scenario then you can imagine the Open XML document being used in a diagnosis process. A clinician opens up an office automation app and documents the patients symptoms into custom fields in the document. When the document is saved the patient data is stored independently as a custom schema in the docx file.

As a next step a billing system picks up the newly created document and embeds a second custom schema into the document that includes invoice information that will eventually make its way back to the patients health-care insurer. An addition to this scenario that is only important in so much as it shows that a single document can have multiple embedded custom schemas. The billing system only needs code to work with the OPC, it does not need to deal with the document, or the diagnosis information.

As a final step, I’ll submit my encapsulated patient transaction to a web service somewhere that analyzes the custom XML document that describes the patients symptoms, and as a result drops a third custom schema into the OPC that details a possible diagnosis and some suggested medication. Again, no office automation involved, and no need for the web service to understand the document or the billing schema.

The original clinician can then reopen the document in their original office automation app and work with all the new information that has been added by various systems.

What is important about the way Open XML deals with this is the segmentation of the data and the ability for the developer to decide up on the structure of the custom embedded schema. This means that the Open XML spec is not dictating how this data is stored, and developers can embed any one of the thousands of XML based business schema standards that exist in the world today. In the example above, for the US, a developer might choose to embed the HL7 schema into the Open XML file.

This capability in itself is a lot more to do with being able to use Open XML in end point systems in a larger SoA environment, and a less to do with what you might traditionally think of in terms of office automation apps, although of course the office automation app still has a key role to play whenever the document reaches a user.

I use a health-care example, but it could be any business process, and I’m already seeing examples of enterprise organizations doing this sort of work in scenarios such as supply chain or banking processes.

Can you do this with other doc formats? Well, most of them just are not designed to do this. The majority of the plethora of document formats that are out there are designed with pure OA or document presentation in mind. For those that do allow the embedding of custom data elements it isn’t clear to me that this data would be protected as it passes through different applications, or that it would possible to implement in a form that allows the segmentation of the data and the conformance to existing business process schema standards.

You can see a demo of how this might look for the user in this video. The demo is based upon work in Microsoft Word, but it could be done in any other application that supports Open XML embedded custom schema.

Jason Matusow has a posting on his blog this morning that explores some of the discussions around the ability for developers to build independent implementations of the Open XML file format and he pulls out some examples, including one of our own here in Asia Pacific.

The ability for independent developers and software vendors to be able to implement the specification in their own products is obviously one of the key benefits that will come with Open XML being a ratified ISO standard.

Due to the characteristics of the Open XML specification there is an expectation that we will start to see implementations offering a range of options including developer tools, office document management, transactional applications and other data communication and management tools. Some examples of these are in the list below.

• Monarch from Datawatch
• XMLSpy from Altova
• iPhone from Apple
• Mindmanager from Minjet
• Gnumeric from Gnome
• Dataviz Documents To Go from Palm
• Open XML IIS Analyzer from Intergen

You can read the full article here, so far it is drawing interesting commentary from those who have been working with the specification.

As we all know, over the last few months there have been a lot of different individuals and organizations looking at the Ecma Open XML file format specification, in many of those cases and as part of their investigation work this has resulted in projects to trial the use of the specification and the file format.

These projects have been dealing with a wide range of issues such as document security, assembly, archiving, or in the case that I’ll highlight in this post data transformation.

Intergen, a New Zealand based ISV, have today released their project to CodePlex, so now anybody can take a look at the work that they have been doing.

Intergen’s Open XML IIS Analyzer provides the ability to convert log files from Internet Information Server into Open XML format which then allows you to build reports in one of the growing number of applications that support this format.

And from the page, here is the project description

IIS Analyzer is an add-in for Microsoft Excel 2007 that downloads and converts server log files into the OpenXML format. Using Visual Studio Tools for Office and the .NET packaging libraries, IIS Analyzer can quickly create reports in multiple formats, including Excel spreadsheets, Word documents and PowerPoint presentations. Log data can also be exported to any SQL Server database.