Several of my colleagues are talking about this today, after four successful technology preview releases the final version is now available. You can download version 2.0 of the Open XML SDK from the Microsoft Download Centre. For those of you working with Open XML documents, today also sees a revamp of the Open XML Developer Centre on MSDN.

For detailed information check out one of the blog entries from Brian Jones & Zeyad Rajabi, Eric White or Gray Knowlton.

Eric White has a great description of the two components of the SDK;

As with the CTPs, the RTM version of the Open XML SDK consists of two principle components:

• A .NET managed class library that provides capabilities for reading, writing, modifying, and validating Open XML documents.

• A productivity tool that includes the ability to diff Open XML documents, a C# code generator, and tools to explore and read about the class library and the standard.

About the Library

Some of the key characteristics of the library are:

• You can use a powerful functional programming approach to write applications that generate documents, spreadsheets, and presentations.

• You can use Language Integrated Query (LINQ) to retrieve data and content from documents, spreadsheets, and presentations.

• You can write code to open, modify, and save documents.

• You can use validation functionality to be more certain that your documents conform to the IS29500 standard and will be able to be opened using Microsoft Office and other conforming applications. Document formats, by their very nature, are involved. The validation functionality in the Open XML SDK is a big help when writing real-world solutions.

About the Tool

Key features of the tool are:

• You can compare two Open XML documents to see exact changes in their markup. This is one of the best ways to learn about Open XML markup. If you want to understand which elements and attributes represent a feature that you want to interact with, create a document without the feature, copy the document to a new document, modify the new document, and compare to the old. After determining the elements and attributes that changed, you can research them in the Open XML specification.

• You can build a document generation program with a minimum of effort. You supply the tool with a sample document. You can then generate C# code that that will generate the entire document, a specific part, or a specific element with its children elements. This code is generated in a style that takes advantage of ‘functional construction’. By this, I mean that any element (or its descendant elements) can be generated in a single expression. You don’t need to write multiple statements. This ability to generate content in an expression instead of a statement means that you can use LINQ queries and projections to formulate new descendant content for an element. It’s a powerful approach.

• The ability to explore the Open XML specification, the implementation notes, and the Open XML SDK class hierarchy in the tool means that you have one integrated tool to do much of the work that is necessary to build sophisticated document generation systems.

Download the SDK

Download the Open XML SDK 2.0 for Microsoft Office
This download provides strongly typed part and content classes for use with Office 2007 & Office 2010 Open XML documents. http://www.microsoft.com/downloads/details.aspx?FamilyID=c6e744e5-36e9-45f5-8d8c-331df206e0d0

Following on from a conversation with one of our customers in Australia earlier this morning I thought it might be worthwhile highlighting some of the more collaborative work we have been doing around interop over the last few years. 

A quick search will find a growing corpus of information, strategy papers with relevance to CxO level staff through to technical information that might be needed by developers on a day to day basis.

For the purpose of this post I’ll highlight just two pieces on the overall jigsaw puzzle, both of them demonstrating some of the work we have been doing to ensure that we’re more closely involved with the community of customers and developers that work with the Microsoft platform.

The first is a whitepaper that we recently published on the work of a group that we call the “Interoperability Executive Customer Council”.

The IECC was formed in June 2006, and it’s members are a cross section of senior executives that represent many of the segments where we do business. The group meets on a regular basis to discuss interoperability issues within six specific work streams, and then collaboratively work on solutions.

The six work streams are detailed in the whitepaper, along with many examples of the issues raised and the work that has been done (and is being done) to resolve them. They are;

Office Productivity and Collaboration Tools. Office file formats; Office programmability and automation; portal, document, and content management servers; back-end and line-of-business application integration; unified communication; etc.
Systems Management. IT operations management; deployment and patching of software; virtualization environments; etc. IT operations want to optimize the management of heterogeneous enterprise environments while providing top-notch service to users based on their service-level agreements.
Identity Management. Identity federation scenarios for providing partners and customers with encrypted access to internal resources; single sign-on (SSO) techniques; user-centric approaches to identity management through third-party providers and relying parties; and Active Directory–Lightweight Directory Access Protocol (LDAP) integration.
Developer Tools and Runtime. Use of different development tools in a distributed environment; robust and high-performance interoperability between .NET and Java/mainframe applications; interoperability with open source languages and tools; consistent implementations of standard cryptology algorithms; etc.
Business Process Modelling (BPM) and Services Oriented Architecture (SOA). Facilitating design, development, and management of business processes to run across multiple platforms and systems using multiple, interoperable frameworks and tools for architecture and modelling.
Public Interoperability Policy. Guiding Microsoft in its approach to the Interoperability Principles and related initiatives, and informing Microsoft’s public policy positions for interoperability, intellectual property, privacy, and security.

Click on the graphic of the whitepaper above to download a copy and read the rest for yourself.

My second example is the “Interop Bridges and Labs Center” which is run by our Interoperability Strategy Group. The site has been around for about a year now and provides details on a growing array of point projects where Microsoft engineers are working with customers, partners or open source projects to solve specific interop challenges.

From the about page on the site;

The Interoperability Bridges and Labs Center is dedicated to technical collaborative work between Microsoft, customers, partners and open sources communities to improve interoperability between Microsoft and non-Microsoft technologies.

The Center is run by the Microsoft Interoperability Strategy Group working with many other teams at Microsoft, with customers input and with the community at large to build technical bridges, labs and solutions to improve interoperability in mixed IT environments.

You will find full details on each of the projects that the team have completed by following this link. The team also maintains a blog at http://blogs.msdn.com/interoperability.

I think this could well be another first for us.

I’ve talked about the importance of the protocol documentation in past posts, but I think this is the first time we have had things written up and available so far in advance of a product launch.

Tom Robertson announced the availability of the Office 2010 protocol documentation this morning on the Microsoft on the Issues blog:

This kind of open access to information is a central tenet in our Interoperability Principles. The aim of these principles is to give all software developers—including commercial ISVs, open source developers, and developers in customer IT departments—technical information that can be useful in building products that work well with our most popular products. All told, we’ve published more than 33,000 pages of technical documentation relating to interoperability with these Office products, and we’ve seen more than 250,000 downloads of the entire range of our interoperability documentation in just the past year.

This model of transparency through access to developer resources has already enabled real-world interoperability in other areas. In December 2008, for example, Microsoft published detailed protocol documentation for Microsoft Exchange ActiveSync (EAS), as part of the expansion of our EAS IP Licensing Program. EAS is the technology that enables mobile devices to synchronize e-mail, calendar and other information with Microsoft Exchange Server. While EAS had been licensed in the past, the posting of this documentation provided consistent, open access for all developers to the Microsoft protocols built into EAS that enable interoperability. As a result, many leading companies—including Microsoft competitors like Apple, Google, Nokia, and Palm—have licensed the EAS protocol patents, making it possible for their customers to synchronize Exchange data on the most widely used mobile phone platforms in the world.

That second paragraph is a great example of how this documentation is being used.

Each year we do something around OSCON that brings us a step closer to delivering on the interop commitments that we have made to the wider IT community.

This year’s Day One announcement is that we’re contributing twenty thousand lines of device driver code to the Linux kernel community for inclusion in the Linux tree, and doing so under GPL v2.

Peter Galli was the first to talk about it over on Port 25:

The drivers will be available to both the Linux community and customers, and will enhance the performance of the Linux operating system when virtualized on Windows Server 2008 Hyper-V or Windows Server 2008 R2 Hyper-V.

In an article posted to Microsoft’s PressPass site, Tom Hanrahan, director of Microsoft’s Open Source Technology Center, notes that this is a significant milestone because it’s the first time the company has released code directly to the Linux community. "Additionally significant is that we are releasing the code under the GPLv2 license, which is the Linux community’s preferred license," he said.

… and Hank Janssen followed with another post on Port 25, where he included the following bullets;

• Yes, our device driver code was released directly to the Linux Kernel
• We released the code under GPL v2
• We are working with Greg Kroah-Hartman so it is ready for the next release of the Linux Kernel, version 2.6.32
• We will continue to update the driver code to enhance interoperability on an ongoing basis, but it’s our hope that other developers in the community will find the code useful and worthy of collaboration.

Microsoft developed the Linux device drivers  to enhance the performance of Linux when virtualized on Windows Server 2008 Hyper-V.  My team and I were responsible for testing and validating the driver components that were contributed for this first release. 

The commentary I have seen so far has been factual and positive.

Todd Bishop has an FAQ with Greg Kroah-Hartman, good answers to questions I know some of you will be asking;

Where the Microsoft code will fit in: "We include all drivers into the main kernel source tree. So you don’t go and download external drivers somewhere, it just all comes included. Now, when you build it, you select all these different options on what you want built and what you don’t want built. Distributions build everything as a loadable module, so that it doesn’t take up any space in your memory, unless you want to use it, unless you have that specific piece of hardware. So in this case, if you happen to want to run Linux on top of (Microsoft) Hyper-V, you just will load these modules and away you go."

John Fontana over at Network World has a fun quote from Jim Zemlin;

"Obviously we are tickled about it," said Jim Zemlin, executive director of the Linux Foundation. "Hell has frozen over, the seas have parted," he said with a chuckle.

And finally Ina Fried has her usual comprehensive view of what this is all about for Microsoft and for Linux;

Although Microsoft has released open-source code in the past, the company has generally favored licenses other than the GPL. That said, the GPL is the way into the Linux kernel and Microsoft wants this code in Linux.

In an article on its press Web site, Microsoft acknowledged the departure. The company has also been going after Linux for years, both on the marketing and legal fronts.

"Today, in a break from the ordinary, Microsoft released 20,000 lines of device driver code to the Linux community," Microsoft said. "The code, which includes three Linux device drivers, has been submitted to the Linux kernel community for inclusion in the Linux tree."

The move comes at a time of mixed signals from Redmond when it comes to Linux. Microsoft has said that the browser-based versions of Office, which are due out next year as part of Office 2010, will support Firefox, bringing at least a portion of Office to Linux for the first time.

Personally, I don’t think our signals over the last few years as being the least bit mixed, a commitment to interoperability is just an issue of the market realties and customer demands of today vs. a decade ago.

Can I say, “I’m still a believer”?

I’m surprised I missed this, I’ve been a little distracted by my recent move.

It seems that back on the 16th June OpenXPS, the Open XML Paper Specification, was approved as an ECMA standard by their 97th General Assembly meeting, OpenXPS will be known as ECMA-388.

A basic outline can be found on the specification download page;

This Standard defines OpenXPS, the Open XML Paper Specification. OpenXPS describes a set of conventions for the use of XML and other widely available technologies to describe the content and appearance of paginated documents. It is written for developers who are building systems that process OpenXPS content.

A primary goal is to ensure the interoperability of independently created software and hardware systems that produce or consume OpenXPS content. This Standard defines the requirements that systems processing OpenXPS Documents must satisfy in order to achieve interoperability.

This Standard describes a paginated-document format called the OpenXPS Document. The format requirements are an extension of the packaging requirements described in the Open Packaging Conventions (OPC) Standard. That Standard describes packaging and physical format conventions for the use of XML, Unicode, ZIP, and other technologies and specifications, to organize the content and resources that make up any document. They are an integral part of the OpenXPS Standard, and are included by reference.

Many XML-based building blocks within OpenXPS make use of the conventions described in the Markup Compatibility and Extensibility Standard that is relied upon by the OPC Standard to facilitate future enhancement and extension of OpenXPS markup. As such, that Markup Compatibility and Extensibility Standard is included by reference.

The specification itself has yet to be posted, but will be available from this link once it is.

For those wanting to find out more, Stephen McGibbon provides pointers to an explanatory whitepaper in XPS and PDF format.

Back in June last year I posted an entry on this blog titled “My way or the highway…” at the time I was exploring the parallels (or lack of them) between the way that we “debate” as a technology community and the way that ministerial and other senior policy makers deal with ambiguity. I was reminded of that post today as I watched the discussion around the implementation of ODF spreadsheet formulas play out on various blogs.

For anybody who has not been following the discussion, you will find a neatly potted history by reading over a few of those posts. Rob Weir’s post on formula interoperability appeared within a few hours of SP2 being released, Doug Mahugh expanded the conversation by outlining how we got to where we are, and PSC’s John Head has a very balanced post titled “And in this corner…” that brings a much needed element of reality back to the conversation.

One of the few press articles I have seen on the subject comes from Victoria Ho at ZDNet Asia.

Finally my colleague Gray Knowlton posted overnight, questioning the motives of the ODF co-chair in this discussion. Personally I don’t agree with Gray’s conclusions or suggested changes, but I do wholeheartedly agree with the premise of his post.

I’ll explain.

I’ve now spent the best part of two decades working with standards organizations, if there is one word I have heard more than any other during that time it is “consensus”. It is in the spirit of consensus that things get done, agreements are made, compromises are reached and standards are developed and published. The standards professionals that I have met are a unique breed of people, often managing to take dramatically different points of view and find middle ground that meets the majority of the goals carried by those participating in the discussion.

At this point my experience of the discussion around ODF is pretty unique when I compare it to many of the other conversations that I find myself involved in that relate to standards development. On the whole standards development and implementation is full of champions, people looking for consensus around complex issues and demonstrating positive support for the standard or technology that they’re passionate about.

The conversation around formula implementation in Office 2007 SP2’s ODS documents epitomizes the one hurdle that I see as a potential stumbling block for ODF’s overall long term success. Bill Gates once joked that many of our competitors were so focused on competing with Microsoft that they were forgetting to innovate and improve their own products – sitting here in Microsoft and watching the debates around our implementation of  ODF I can see some parallels there.

To succeed ODF needs it champions, I know they are out there, I’ve met a few of them, for what it is worth (and contrary to Gray’s view) I believe IBM’s Rob Weir is one of them – on a good day.

I’m pretty sure that some of the louder voices in the ODF community today are helping corporate compete with corporate, I’m not convinced that the broad implementation and success of ODF itself is at the heart of those conversations – it needs to be.

You may remember that a little under a year ago Microsoft talked about a commitment we were making to support ODF 1.1 in Service Pack 2 for Office 2007.

Since then the subject has come up from time to time as we have discussed the details of this commitment, initially with some discussion around what we described as our guiding principles for implementation of the file format, then at the various Document Interoperability Workshops that we have been running around the world, and then most recently when we released the detailed implementation notes for the work that we have been doing with the ODF file format.

Earlier this week it all finally went live, with full support for ODF 1.1 in Word, Excel and Powerpoint.

Doug Mahugh has an excellent post where he talks about how to work with ODF in the Office applications, from minor points such as switching style sheets through to offering users the option to select ODF as their default file format.

If you’re looking for more information on Service Pack 2 (there is a lot more in there than just ODF support) then Gray Knowton has outlined a number of other features of the SP, along with the many KB articles that are encapsulated within it.

The final blog post from Microsoft that is worth a look (I’m sure there are others!) comes from Stephen Peront and discusses the new Converter API that is now supported by the Office applications. This API gives developers the ability to build their own custom file format filters for Office, a feature that I think will open up many new options for our users over time.

Over the last year I’ve been involved in several external and internal discussions that have brought us to this point, and I have to say that I am really proud of how far the Office team have come with this and some of the standards (little “s”, non-technical) that they have laid down for themselves and the wider industry along the way.

Building a conformant implementation of ODF1.1 into Office is only one step, the work that has been done to document the implementation notes for this work, build community around the work that is taking place in this space in the form of the DII events and stand up a robust internal team to manage our standards work that relates to the Office applications lay some great foundations for future versions of the product.

Finally I am going to suggest something that I don’t think I ever have before on this blog, nor did I ever think I would, and that is to read through a /. discussion on this topic that took place over the weekend. The discussion appears to have moved on a long way from two years ago when the answer was “if it is open source, and a published open standard then it will just work”. Of course you will still find the traditional Microsoft jibes that you would expect on /., but there is also some discussion around the merit of implementations, some praise for the work that we have done here and some concrete suggestions for work that now needs to be done by other parties to further the overall interoperability agenda.

I’ve talked before about how achieving interoperability is not going to be about just Open Standards, but also about product design, about community and about sharing of information – the goal of achieving interoperability between office suites will need all four of those activities, we need participation and collaboration in all four areas by a diverse array of parties.

I loved this quote from a Dr. Kevin Hughes (a surgeon at Massachusetts General Hospital) that was published in New Zealand’s ComputerWorld earlier this week.

… a story titled, “E-health records not enough, experts say”;

“We don’t have interoperability within electronic health records, much less between electronic health records,” Hughes said. “A lot of the party line on electronic health records is that we need to regulate that doctors must use them … but why don’t we make them better, so they want to use them?”

I have to agree… it always seems to make more sense to me when people talk about users adopting technology because they want it rather than because they are regulated to use it.

On the other side of the pacific, the US administration as appointed one Dr. David Blumenthal to look after this problem on behalf of US healthcare system. For anybody who missed it, there is over US$19bn allocated to healthcare IT systems in the recent US economic stimulus packages.

ChannelWeb’s “Obama Names New National Health IT Coordinator”;

The Obama administration on Friday named Dr. David Blumenthal the new national co-ordinator for health information technology.

Blumenthal will replace Dr. Robert M. Kolodner in what is seen as a key post in the Department of Health and Human Services, given the president’s ambitious health-care agenda and the more than $19 billion in health-care IT funds allotted in the federal stimulus package. About $2 billion of those funds are allotted specifically for HHS.

Blumenthal comes to Capitol Hill from Massachusetts, where he was most recently a physician and director of the Institute for Health Policy at Massachusetts General Hospital/Partners Healthcare System in Boston. He is also a former Samuel O. Thier Professor of Medicine and Professor of Health Care Policy at Harvard Medical School, and before that a senior vice president at Brigham and Women’s Hospital in Boston and executive director of the Center for Health Policy and Management at Harvard’s John F. Kennedy School of Government.

The idea of an interoperable EHR seems to be gaining an increasing amount of mindshare (and funding) around the world. Maybe 2009 or 2010 will finally be the year when we see EHRs become a reality.

A post appeared on New Zealand’s publicaddress.net blog earlier this week which I thought was fantastically insightful.

The site invites guest bloggers from around New Zealand to post on whatever topic is dear to their heart, this one in particular is purported to be written by an anonymous member of New Zealand’s civil service.

Here’s an excerpt from the anonymous civil service blogger;

What we tend to do (certainly for our first few years in the public sector) is think of great ideas to make our systems more efficient. Often we’ll find a sympathetic manager and say “why don’t we do X? That would make things easier / cheaper / faster for people”.

Then we hit the problem. You see, we’re drowning. Our collective heads are almost disappearing under the waves because of lots of well-meaning law and process that has actually resulted in a bad outcome. These things were done with the best of intentions, based on good theory. But when coupled with media serving people with the attention span of a goldfish, have ended up making it impossible to actually get anything done.

When we all embarked on our big eGovernment programs over a decade ago there was lots of talk of the need to redesign internal processes and how we should be careful not to just deliver electronic variations of existing processes. There are a few rare cases where that has happened, but many governments around the world have ended up computerizing the process that they already had, cutting costs but delivering only small additional incremental value to their constituents.

It is easy to forget how hard it can be to get things done when you are embroiled in the complex machinery of government. If you want an example, consider working with online services with the UK government in the late 1990s and bumping into policies laid down by Cromwell’s Instrument of Government over four hundred years earlier that made it difficult to share date between agencies.

Many eGovernment programs in the 1990s were thrown into the heart of departmental and national modernization programs. The technology brought great advantages, allowing service providers to cut complexity out of their processes, but it was rare that the technology itself was able to drive the level of wholesale change that was expected and needed.

Like the interoperability challenge, technology is an enabling tool. There is still an opportunity to think through how the organization and process of government needs to change to deliver against those policy goals.

The goals of eGovernment programs remain the same, the civil service are working hard on ways to use technology to cut cost and find new ways to serve their constituents. At the same time many of our political leaders have lost interest in eGovernment or online services and have moved onto more interesting and more pressing challenges.

2009 is a year when we once again need to think hard about how we can simplify government, how we cut back on costs and complexity, and how we make it easier for the civil service to do more with less. This time the pressure is financial, a challenge that the machinery of government is skilled at understanding. Technology will play a pivotal role in helping governments meet these challenges, but we also have to be ready to address the harder issues of organization, process and the supporting legal infrastructure that both are based upon.

We have made some great progress with eGovernment programs over the last decade, but the job is not done. It is only when issues of organization, process, technology and legislation are dealt with as a single program that we will see the real benefits of eGovernment.

Maybe this year, more than most, there is motivation to finish what was started.

If you do nothing else, you should read through the entire post from New Zealand’s anonymous civil service blogger.

Almost ten years ago I was involved in the process to write one of the first eGovernment Interoperability Frameworks, the eGIF work in the UK.

At the time we had some big interoperability decisions to make, ones that were fundamental to the issue of connecting basic infrastructure. In the government at that time there were no definitive decisions about how some of the basics might work, would we connect systems together using TCP/IP, OSI TP0/TP4 or SNA? would we move email around using the incumbent X400 protocol or adopt the emerging SMTP standard?

Version one of the UK eGIF really helped departments at all levels in government think through these fundamental issues.

Today those same issues look a little brainless, the wider market has made its decision and we all know and the protocols that run the internet provide the same basic answers to government, citizens and enterprises.

The EU, with the first version of the European Interoperability Framework, took this thinking one step further and introduced the concepts of multiple challenges within government to solve the interoperability challenge. The document extended the Interop domain challenge to look at organizational challenges and semantic language challenges faced by departments who are working to connect services together, while keeping the technical guidance that countries like the UK had worked on as a third tier of activity.

Today many countries around the world have adopted this same approach, at the very least documenting lists of technical standards that can be adopted across government and in many cases adopting the same three tiers of interoperability policy activity that the EU project originally defined.

When I look at many of these documents today the technical chapters have evolved hand in hand with the way that the market has evolved, but stepping back they’re starting to look a little odd – at least to me.

Many of the basic technical challenges have been solved by the industry and adoption of those standards has been driven by consumers and businesses. To me it no longer seems necessary for governments to spend time maintaining a document that pushes departments to select TCP/IP for networking, or HTTP/HTML support in web based applications and browsers. These things are still important, but it is probably time to take a step back and think through what is really inhibiting the delivery of joined up services in governments today.

While there is still a high level of focus by governments on the technical aspects of interoperability, there only appears to be a limited increase of activity on the other two complex challenges that we collectively face.

For any country looking at solving interoperability challenges at a national level today I would suggest a very different approach to the one we took in the UK a decade ago.

In many cases (certainly not all cases) the technology will support the levels of interoperability needed to connect systems together, but it can still be very challenging to get departments to work together and answer the core organizational questions that need to be answered before they can deliver a seamless business process. Assuming that the organizational challenges do get solved, then the semantic language issue is equally in need of rigorous academic work and policy focus.

Interoperability, on the level needed to deliver eGovernment connected services, isn’t a technical challenge today. In many cases the organizational and semantic language issues need a lot more focus. If we are going to see governments meet the goals of common and unified service delivery then we really need to see more work in these two areas, and accept that the evolution of the internet has resolved many of the technical challenges that we set out to solve in London ten years ago.