Latest CTP of OXML SDK reflects its ownership shift

Microsoft is just another contributor to the OXML (formerly OOXML) community now, and today the work it has been doing to build developer tools for what's now an international standard, has been changed to reflect that new status.

Work at Microsoft on the system developer's kit for the OXML format suite continues mostly on schedule, with a Community Technology Preview released today in advance of a final 1.0 release now moved back a few weeks to June. But it's no longer the Microsoft SDK for Office Open XML Formats. Instead, it's just another effort (assuming there could be others) to build programmable access to Open XML formats, as Microsoft is now referring to it as just the Open XML Format SDK.

Also being expunged from Microsoft's vernacular is any reference to the OXML "object model," a term from the COM days when methods and properties were exposed through interfaces and activated through container objects. In its place will be the phrase "Open XML API," which was changed to maintain compatibility with the concept of the format suite as its new stewards, the ISO and IEC, now perceive it.

For now, according to a blog post today from Microsoft developer Erica Ehrli, the 1.0 edition of the API (which is referenced using the SDK) will include just one of the programmability components Microsoft is planning. That will be the Packaging API, which a .NET developer would use to either create an OXML document, or directly access the contents of an existing one. It's mainly for getting XML out and putting new XML in, and depending upon which part you're referencing, the 1.0 edition will be released in May (on the chart) or June (from the text accompanying the chart).

Early examples of the Packaging API in action, including this one from the Office Developer Center, are a bit crude and actually do resemble some of Microsoft's first efforts at jerry-rigging libraries such as ODBC to be addressable from Visual Basic.

Conceptually, it's not difficult; but then again, neither is changing the oil in your car. In one VB example of putting code into a fresh OXML word processor document, in a public procedure, you declare a new variable as type WordprocessingDocument, and you set it by default to the result of the .CreateWordprocessingDocument method. You then use another method to declare a second variable as the main body of that document, so the XML you add doesn't get spilled into the header.

That second variable will then have a method associated with it, .GetStream. Its results can be assigned to a new variable that then represents the stream -- the channel of input into the document. Then you literally declare a Const (constant) of type String to which you assign the XML you wish to add to the stream -- and as VB programming veterans know, multiple-line variable assignments aren't pretty, a bit like hauling an outdoor swimming pool in the back of a minivan.

Of course, with the entire text of the XML condensed to a Visual Basic string, it's not beautified with structured tabs, either. But that's just the initial example, and more robust concepts using the new API probably aren't that raw.

The heart of the Open XML programmability process will come with the 2.0 edition of the API, when Microsoft adds the management languages (MLs). This could be where an independent program can interact more intimately with the application responsible for originally generating the document -- and as we now know, we can't just assume that application belongs to Office.

Microsoft will be dividing its additions to the 2.0 API into three components, the first of which -- incorporating the word processing and shared facilities ML -- could see the light of day at the same time the 1.0 SDK is released. The spreadsheet ML will follow in the early fall, and the presentation ML could be released sometime in early 2009. As Office programming veterans will note, PowerPoint was never Microsoft's first priority in the programmability department.

Ehrli stated on her blog that Microsoft's intent in releasing the roadmap now is to enable developers to utilize its so-called "Go-Live" license, which frees them to go ahead and deploy solutions in the field utilizing the SDK even while the API itself remains under development.