A new SDK for OOXML aims to mobilize developers

There are any number of varying definitions of "interoperability," but developers take it to mean the ability to get into the software and make it work right. So today's announcement from Microsoft of a finalized OOXML SDK could be more important than even a victory at the ISO.

This morning, Microsoft announced that the system developers' kit for Microsoft's Office Open XML document format will officially emerge from the CTP stage next month, as version 1.0. What this will enable is a high-level vernacular for the different components of the OOXML formats, similar in concept to the role that type libraries played in characterizing the old Office 2000 and 2003 binary formats for use in Visual Basic for Applications macros.

But there's a much bigger difference here: The OOXML SDK will expose the most useful components of the format through the .NET Framework, to developers for any of its associated high-level languages. The end result is far more than macros, but the ability to build stand-alone applications that can access the contents of documents logically, without developers actually having to know the ins and outs of the format itself.

"The way I would describe version 1.0 is as a kind of polished version of what was out there for the CTP last year," Microsoft's OOXML senior product manager Doug Mahugh told BetaNews, "and it fills in some of the gaps, [such as] classes and methods for all the key document types, and the high-level elements throughout the format."

By representing categories of the formats' representative elements as classes, and functions that can be expressed for locating contents or even changing them as methods, the SDK serves as an extension of developers' existing programming vernacular. It adds new keywords to their existing grammar, rather than forcing them to explain and accept a whole new context of logic.

For example, Mahugh shared with us, a word processing document has any multitude of textual styles. You don't have to understand OOXML and how it regulates those styles in order to use the SDK to retrieve information about them (font, point size, leading, paragraph margins, indentation, etc.). Instead, you use the simple class term Styles. (with the trailing period), followed by the property name that represents the characteristic you want to retrieve. Styles can be enumerated, so you could conceivably use a value to refer to a specific style in a list, and then of course, use a variable to represent that value.

This way, developers can continue to write their code at a high level, avoiding the low-level semantics of the standard. "The SDK is smart enough to traverse the tree of relationships to find that [property] and give it back to the developer, and the developer doesn't have to know or care what is the name of that specific XML part within the package," explained Mahugh.

The term software engineers use to describe this manipulation of grammar is "strongly typed." "The SDK gives you a toolbox of strongly typed parts for all the different parts of the package," remarked Mahugh.

The first CTP of SDK version 1 was released last June at TechEd 2007 in Orlando. Since that time, Mahugh told BetaNews, he's received a tremendous amount of feedback, a good deal of which was incorporated into next month's release...though not all of it.

After April, the pace of OOXML toolkit development is slated to accelerate dramatically. Just three months later, said Mahugh, he expects to be ready with the CTP of Version 2 of the SDK. "This is where we're really going to build in some of the cool feedback, during the CTP phase [of version 1]."

At that time, he said, developers can expect to see higher-level and more task-specific abstractions, including terms specific to word processing, spreadsheets, and presentations as opposed to generic documents. Other enhancements will improve the SDK's interoperability with other XML development tools, such as "Link to XML." There will also be extended support for language enhancements in C# 3.0.

Following the release of the CTP for the version 2 SDK in July, the final edition will be tied to the release of Office 14...which should give you a dramatic new comprehension of how soon that product may actually be upon us. Remember, the version 1 SDK was only released last June. Mahugh declined to set a specific date for Office 14, though if history is any guide, the spring after next could be a fairly busy one.

In this new world of software where it genuinely seems there's more vendors than just Microsoft, interoperability takes on a many-faceted meaning. In Doug Mahugh's mind, the OOXML SDK will be just one interoperability tool for the format among many, in his case, specifically for the .NET Framework. There are other frameworks to consider.

As he explained to us, "Any given developer is writing on some platform. So for developers who are writing on the .NET platform, this SDK will now be the highest-level, most productive tool for them to read and write the Open XML formats. There are similar APIs like the Open XML for J project in France, that is a Java API...or the PHP XL API out of Belgium...Depending on what platform you work on, you use the tools available for that platform to create documents that then are interoperable across other platforms as well. Because when the document is created, it doesn't matter where the code ran that originally created it.

"If you look at Open XML for J," Mahugh continued, "Julien Chable has done what our team has done with our SDK: He's looked carefully at the spec and tried to come up with some abstractions that, as an experienced Java developer, he thinks would be useful to Java developers to help them be more productive reading and writing these formats. So everybody's doing the same thing there, in that we're all looking to the standard and saying, 'What kind of tools might a developer want to enable them to work very effectively and efficiently with a standard?"'