OSRIN.net

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.

Infoworld’s Neil McAllister has compiled a list of what he counts as the top twenty greatest blunders in tech history.

Some of them are not quite so much blunders as they are examples of entrepreneurs or innovations that missed the mark with their ideas.

IPv6 gets a mention;

12. IPv6. Few topics spark more debate than IT’s equivalent of global warming. According to some experts, the question isn’t whether we will run out of IPv4 network addresses, but how soon. And there’s no Kyoto controversy here; federal policy already requires that government offices transition to IPv6 by 2008. So why is everyone still dragging their feet? Quite simply, IPv6 is a fix for a problem nobody has yet. Stopgap solutions such as NAT, while infuriating to network engineers, have proven effective. And IPv6 offers no compelling features to offset the headache of implementing it. In other words, until someone offers the equivalent of carbon credits for networking, IPv6 is one truth that’s just too inconvenient.

His point on IPv6 is pretty much spot on. As technologists we can see a point when NAT will just not offer enough headroom for adding more users to the internet, and we can see the opportunity that comes from devices and sensor networks that would be enabled by IPv6 deployment.

Despite that I still don’t think anybody has done a sound job of expressing all this in terms that our political and business leaders can take hold of.

Maybe now, in these times of infrastructure focused stimulus packages, we will see governments investing in IPv6 enabled infrastructure. To date though, across all of the countries that I’m tracking, I see no such initiative.

This year will be a focusing one for those folks who are involved in promoting IPv6 deployment, they will be thinking in terms of the benefits that IPv6 will bring to local and international ICT markets and working out how to express that to political and business leaders in terms that make sense to them.

What new types of applications can they see? How many more people will be employed as a result? How many new businesses might exist if IPv6 was enabled in their country today? and of course, What is the net addition to GDP that will eventually result from deployment of IPv6 infrastructure?

The focus on infrastructure in these stimulus packages isn’t because building a bridge will employ a few hundred road workers, it is because a new bridge will connect communities, open up new trade routes, make commuters more efficient while also giving them access to new job markets.

The argument for IPv6 is similar in many ways, we just need to get beyond the technicalities of the discussion and focus on the advantages that deployment brings.

There is lots of chatter all over the web about this today, here is the link to Mary Jo-Foley’s blog;

The deal, announced on February 16, has two components, according to a posting to Microsoft’s Port 25 open-source blog. Red Hat has joined Microsoft’s Server Virtualization Validation Program (SVVP) and Microsoft has become a Red Hat partner for virtualization interoperability and support. According to Microsoft’s Open Source Community Manager Peter Galli, Microsoft also will be added to the Red Hat Hardware Certification list once the Red Hat certification process is completed later this year.

Matt Asay added; (my highlighting)

Both Red Hat and Microsoft on Monday lowered their guns long enough for customers to win. They did so without encumbering interoperability with patents, which will be critical to ensuring that Microsoft can lower its guard further to welcoming open-source solutions to the Windows fold as a full partner.

On my part this feels like a good move for us and for Red Hat, I know it will resonate well with customers here in Asia.

A full explanation of the agreement can be found in the press announcement that Red Hat put out today.

During my session Q&A at the Taiwan Academic Summit in Taitung over the weekend I promised to share links to resources and information about the work we’re doing to improve interoperability across both our products and the industry.

Here are a few to get you started;

• Newly created Interop blog – http://blogs.msdn.com/interoperability/ 
• Information on Microsoft’s work with Standards – http://microsoft.com/standards
• Links and blogs outlining the work we’re doing with Open Source Software – http://port25.technet.com
• Microsoft Interoperability Principles – http://www.microsoft.com/interop/principles/default.mspx
• Interop Vendor Alliance – http://interopvendoralliance.org/default.aspx
• Document Interoperability Initiative – http://www.documentinteropinitiative.org/
• Novell & Microsoft Interop work – http://www.moreinterop.com/
• Links to many other Microsoft resources relating to Interop – http://microsoft.com/interop

And finally, links to individuals who are blogging on a regular basis on interop related topics and Microsoft’s activity in this area;

Brent Phillips, Brett Roberts, Brian Jones, Craig Kitterman, Dino Chiesa, Doug Mahugh, Eric White, Gray Knowlton, Jerry Fishenden, Kim Cameron, Stephen McGibbon

Jean-Christophe Cimetiere has some more information this morning about the tools that are being built to allow Eclipse developers build content for Silverlight 2.0, I first shared the outline of this project in October last year.

His post this includes a little on the history and current status of the project, and ends with details of how to download the tools for yourself;

The Eclipse tools for Silverlight project, aka eclipse4SL, is an eclipse plug-in that enables Eclipse developers to use the Eclipse IDE to create applications that run on the Microsoft Silverlight runtime platform. Announced in October of last year, the project is led by Soyatec, an IT solutions provider based in France & China, and also an Eclipse Foundation member (Yves Yang, Soyatec President). Microsoft provides funding and architectural guidance (in particular my colleagues Vijay Rajagopalan and Stève Sfartz).

Since the release of a new beta version in December, additional technical content for Java developers has been published on the project site, giving guidance on key interoperability scenario sought by developers: facilitate interoperability between Silverlight clients and REST and SOAP (JAX-WS/CXF) Java web services.

He also included a brief video discussing the tools and how to use them.

If you’re interested in taking a look then you’ll find a step by step installation guide here.

Finally some advice on finding some sample code to play with and getting started;

[…]explore the Hello, world and DataGrid tutorials that my colleague Stève Sfartz has prepared for you. Also you might want to check this tutorial that has just been posted on Devx: Getting Started with Silverlight for Eclipse.