gov·ern·ance

1. government; exercise of authority; control.
2. a method or system of government or management.

man·age·ment

1. the act or manner of managing; handling, direction, or control.
2. skill in managing; executive ability: great management and tact.
3. the person or persons controlling and directing the affairs of a business, institution, etc.: The store is under new management.
4. executives collectively, considered as a class ( distinguished from labor).

From WikiPedia;

Governance. … is the activity of governing. It relates to decisions that define expectations, grant power, or verify performance. It consists either of a separate process or of a specific part of management or leadership processes.

Management. …in all business areas and organizational activities are the acts of getting people together to accomplish desired goals and objectives. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. Resourcing encompasses the deployment and manipulation of human resources, financial resources, technological resources, and natural resources.

Since I first got involved with eGovernment projects in the mid-nineties I have been encouraging governments that I have been working with to look towards international standards as a route to solving system interconnect challenges, an important step on the path to providing more predictable and useful services to the citizens and businesses that they work with.

More recently, along with everybody else in my field, I have found myself increasingly involved in eGovernment projects that are using Web2.0 technologies (sometimes called Gov2.0) to improve the way that they work with their constituents.

Working with these projects I have become aware of two factors that have changed the way that I think about a subset of the communication standards that the projects rely upon.

1. Companies like Facebook and Twitter are still evolving, rapidly and in real time. To maintain their pace of innovation they need to be able to constantly update the APIs and protocols that clients use to interconnect with them.
2. As software development has become more agile it is increasingly easier for developers to keep up with these rapid changes. The myriad of twitter clients that change as the TwitterAPI changes is a good example of this agile software development in action.

This change has led me to think more about the evolution of innovation, and when it should and should not intersect with a standardization process.

The whole curve introduces more complexity than would be suitable for this blog post, however to drive the conversation of today’s topic I would suggest that at the start of the curve, while services are still evolving and users requirements are still being understood, it frequently not appropriate to standardize these emerging technologies.

At the same time as companies like Twitter and Facebook have adopted a policy of publishing the details of their interfaces in an open and transparent manner they have provided a platform that is suitable for governments to adopt, in the way that those same governments could only have adopted internationally peer review standards in the past.

The Gov2.0 projects have introduced us to an era where we do see governments adopting technology that we would have considered emerging and unstable in previous years, and they are adopting those technologies with  success and a great deal of support from their citizens.

We have a new form of standardization that happens in real time, and governments around the world are already embracing it.

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

Conversations about the governance of standards setting organizations will from time to time stray towards the topic of reform, along with the need for simplicity in the standards development process. I would argue that the complexity that we deal with today is both necessary and an important component of a functioning ICT industry.

Today SSOs are very diverse. Almost all of them produce both effective standards and standards that never achieve marketplace acceptance. But the flexibility, competition and choice that this ecosystem provides is healthy for the ICT industry. The processes by which ICT standards are created can vary greatly and are constantly evolving. Formal ICT standards are developed in formal SSOs, industry consortia, professional associations, and other industry groups. Many of these diverse organizations have open and published processes that allow all relevant stakeholders to participate and help to balance conflicting requirements. Other ICT SSOs are more focused and less formal collaborations, which can produce needed standards that are very targeted in nature or which can incubate standards for further standardization at a more formal SSO.

While this diversity and breadth of SSOs can be perceived as overwhelming, the truth is that it has emerged as a result of the market in which we all operate. It provides for flexibility, competition and choice. No one process can guarantee that every standard it produces has some level of immediate intrinsic value. No one standards body or process necessarily produces “better” standards; again the test of success and relevance of a standard is the extent to which it ultimately gets used in the marketplace. (As an example, the IETF TCP/IP standard became much more widely implemented than the ISO OSI standard despite the fact that ISO has produced many other very successful ICT standards.) SSOs routinely review their activities, procedures and policies, and they make improvements and changes as needed.

Standards-setting organizations also have collaborative actions and liaisons between themselves, and with other bodies that support related conformance or interoperability testing, business initiatives and so on. Many standards make references to other standards coming from other SSOs or have ratification processes that they apply to other SSOs’ work.

There is certainly no shortage of people who find the diversity of SSOs confusing and frustrating, and from time to time I find myself in that camp. However, any conversation about making changes to the broad array of standards setting processes that we know today has to dig deeply into why we are where we are, and has to recognize the many successful standards that are already implemented by in hardware and software by many hundreds of developers using every possible language and from every possible discipline.

While the subject of reform is an important discussion point when it comes to SSO governance we risk the word bringing an unnecessary level of drama along with it. What I would personally rather see is a broader array of voices collaborating in the ongoing work to evolve the process that we have today to meet the needs that we know the industry will have in years to come.

We have a proven, solid and working standards setting system in place today and in my view it is important that as a community and as an industry we continue to build upon that

Well described and semantically tagged data is always going to be at the top end of that spectrum, with the additional metadata making it clearer to the developer what the purpose of the data is and how it can be used. 

I’ve talked before about how much work a government agency might want to put into publishing their data, and conversely how much use that data then is to consumers. With additional usefulness comes additional cost, complexity and governance. Individual governments will decide for themselves how far along this path they want to walk.

The Resource Description Framework (or RDF) has been around for the best part of a decade and was designed, in part, on the basis that we would eventually see massive amounts of machine processable data and information published for consumption on the web – exactly as we are beginning to see as governments publish various national and state level datasets.

As additional background reading on the topic, Tim Berners-Lee talks about how RDF might apply directly to Open Government Data in his June 2009 article: “Putting Government Data online”.

To help explain the concept the W3C have published a comprehensive RDF Primer, which begins with the introductory text;

The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, copyright and licensing information about a Web document, or the availability schedule for some shared resource. However, by generalizing the concept of a "Web resource", RDF can also be used to represent information about things that can be identified on the Web, even when they cannot be directly retrieved on the Web. Examples include information about items available from on-line shopping facilities (e.g., information about specifications, prices, and availability), or the description of a Web user’s preferences for information delivery.

RDF is intended for situations in which this information needs to be processed by applications, rather than being only displayed to people. RDF provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. The ability to exchange information between different applications means that the information may be made available to applications other than those for which it was originally created.

… it then goes on to say;

[..] while English is good for communicating between (English-speaking) humans, RDF is about making machine-processable statements. To make these kinds of statements suitable for processing by machines, two things are needed:

• a system of machine-processable identifiers for identifying a subject, predicate, or object in a statement without any possibility of confusion with a similar-looking identifier that might be used by someone else on the Web.
• a machine-processable language for representing these statements and exchanging them between machines.

Anybody with an interest in this area should read both the full RDF primer and the W3C homepage for RDF.

As one further point I thought it might also be useful (in a slightly self serving way) to dig around and find areas where Microsoft has been working with RDF in either research projects, products or within various developer tools.

With the help of a colleague in Redmond we came up with the list below. It is not exhaustive, but does gives a representative sample of the type of work that the company is doing in this area;

(Portions of this article quote the WC3 Primer on RDF which is held under the Copyright of the W3C, full notice and further information: Copyright © 2004 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.)

There is no debate that standards have always played an important role in the design and delivery of eGovernment systems, since the mid-1990s we have been seeing standards play critical roles in data exchange, authentication and the way that information is ultimately presented back to the user.

Early eGoverment systems represented a small revolution for many governments, providing ways to increase levels of administrative efficiency while at the same time providing services that were much more broadly available than in previous years.

However, if we turn and look specifically at agencies responsible for archiving governments information then the shift to digitally delivered services also brought some new challenges. Archiving paper is well understood, archiving digital records adds complexity that is still being worked out in many jurisdictions. Only now are we starting to see standards emerge for storage and maintenance of these digital records, over ten years after we saw the mass shift to digital by governments all over the world.

The issues will be obvious to many, governments have a decade wide void in the records that they have managed to keep, information has been simply lost as individual computers and email inboxes have been redeployed or the hardware has been recycled.

At this point in time we are witnessing a second iteration of that revolution, governments, citizens and businesses are collaboratively talking about Government 2.0 (or gov20), examining ways that they will use microblogging, social media and the publishing of massive government datasets to find new ways for government to interact with citizens and for developers to deliver a range of tools that could not be developed by government alone.

Within these gov20 conversations we are seeing more than just the digitization of government services, politicians are finding new ways of communicating directly with their electorate and senior departmental officials are finding new ways to more deeply understand the people that their services ultimately serve.

So once again we are seeing a massive shift in the technology that is being used to run the business of government, and once again we don’t yet have the standards to retain the conversations that take place over microblogging services, or the huge amount of inbound information that departments will eventually use as part of their decision making processes that they collect from an array of social networking tools.

As a standards community, in support of the ongoing evolution of eGovernment, now is the time for us to start to think about how we will solve these complex challenges. Work needs to begin on archiving standards that will retain the information that is driving decisions today and as technology plays an increasingly larger role in the business of government archiving standards needs to be a core part of systems design, not a problem that we try and solve after the fact.

For governments, the digital revolution presents some important challenges, including how best to ensure that their digital documents will be accessible and readable essentially forever, regardless of how technology evolves. This is a question I encounter often in my role as a Regional Standards Officer, working with various public agencies in Australia and New Zealand that have responsibility for archiving records and other documents.

Fortunately, the challenge of e-archiving has been addressed over the past decade or so through standards development and other collaborative efforts around the world. International standards offer guidance on how to capture documents and how to use metadata to ensure that they can be located and understood by future generations. Published specifications for the Open Document Format (ODF), Open XML and Portable Document Format (PDF) also ensure that documents in these formats will be readable long after the formats are obsolete.

That said, a lot more work is still to be done.

Although ODF, OpenXML and PDF account for the bulk of documents produced today, other formats need to be documented. Microsoft has put documentation for our Office binary formats, for example, into the hands of the British Library for reference by future generations. We encourage other vendors to take similar steps with their storage formats.

New standards are needed to ensure retention of at least some of the massive volume of data produced in social networking activities, such as the micro-blogging increasingly used by elected officials to interact with constituents. Broad collaboration on enhanced standards and processes would help clarify how much of this data needs to be retained, and how to store it.

Microsoft is committed to working with governments and all other interested parties to meet these challenges and preserve the history of this decade, and the next, and the next.

It seems like a pretty cut and dried debate, if there was a single standard for everything in  the software world then life would be simpler. Wouldn’t it?

Back in the early 90s we thought that we had the whole single standard thing pretty much sorted out. For email we would use X.400, for ethernet communications we would use TP4 and so on.

I was working with many of our public sector customers in the UK at the time, and assisted with a number of projects aimed at delivering X.400 enabled mailboxes broadly across the UK civil service.

In the mid 90s along came the internet, bringing with it with the stack of protocols that we are all aware of today.

The agencies that I had been working with mostly had one of two strategies, either a pure X.400 implementation which at this point would be mostly redundant, or a broad strategy of interconnection with Notes, MSMail, Groupwise, X.400 etc., in which cases SMTP was just one protocol in a list of many and as such could be folded into an existing project plan.

Even then it was not the end of the road for X.400, as recently as three years ago we were still seeing the protocol being implemented in military environments where features of the X.400 specification remained crucial for email in the battlefield.

Moving to today, even given the pain that a number of technologists felt during the 90s, the debate around one or multiple standards in a given technology domain still goes on.

In many cases, if we play this debate out in a technology domain that we all know well then it makes very little sense.

Lets use high speed local area networks as an example. There is an obvious choice for a single standard that will work for everybody in this domain, it is TCP/IP. Isn’t it?

Choosing and mandating only TCP/IP has a couple of effects on my ability to communicate with the array of devices that I might find in any corporate datacenter today. Starting with legacy systems, I might have just restricted my ability to talk to those older systems which could be running protocols like IPX, Netbeui or various mainframe communication protocols that have existed through the years. On the other end of the scale, we’re starting to see and increasing number of devices implement the next version of TCP/IP, IPv6.

So for something as simple as networking it seems we have a need for a range of protocols to deal with all of the systems we might be planning to work with. The majority traffic on the wire will obviously be TCP/IP on any network today, but a percentage of it will be something else, and over time I would expect to see the majority migrate to IPv6 or a protocol that has yet to be developed.

This becomes the case for at least three reasons.

First of all, any evolving datacenter will either have existing legacy systems, or will have a need to connect to external third party customers or partners who are using legacy technologies.

The second is that developers (companies and individuals) continue to innovate in every area of the technology itself. Sometimes that innovation is incremental, sometimes it comes from another group and is ostensibly competitive.

The third is that while many standards look similar at the outset (Netbeui and TCP/IP are both just networking protocols for example) it quickly becomes clear as you delve into the details that they exist because at a point in time a development group perceived a scenario that could not be addressed by the many protocols that had already been defined and made available to the market.

My conclusions are by no means empirical, but I do find that this argument tends to fall on the side of preference for a “single standard” for a given technology domain in a handful of scenarios;

There could be a preference for a particular technology. This one is generally pretty obvious, you will hear something like “there should be a single standard in this area, and it must be my standard” thrown into the debate.

Simplicity of implementation may carry the highest possible priority for a small subset of projects, with a relative disregard for factors like legacy integration or future innovation. This is an interesting line of argument, and in my view only works for stand alone solutions that will have a short life span. Solutions that will never have to communicate with a legacy user community or technologies, and do not have to be ready to deal with innovative technology changes that might come along in the future.

Finally, it can sometimes come down to a lack of information being presented to the group making the decision. When you glance over a particular technology domain, choosing a single standard in that area generally looks pretty straight forwards but when you dig deeper it is rarely the case, as with my example of networking protocols.

Many of the software products that have enjoyed success in the market over the last couple of decades have done so in part because of their support for multiple standards and formats, I suspect the same will eventually be true for enterprise and eGovernment technology solutions that are being implemented today.

It was pleasing to note this morning that the specification has now been ratified by ISO/IEC as IS29199-2.

Bill Crow talks about the process a little on his blog today;

The many innovations delivered in JPEG XR originated from over ten years of research and development at Microsoft.  And through our participation as a member of the JPEG Committee, we’ve been able to deliver additional improvements and create an International standard available to everyone.

So the next question everyone asks is “when will it be available in a camera?”  Since I don’t work for a camera company, I can’t answer that question.  But I’m pleased and proud that because JPEG XR is now a free International standard, there’s very little standing in the way of making that happen!

He also mentions some of the key benefits of the format;

Better compression – JPEG XR offers improved efficiency compared to JPEG, and the type of compression artifacts are often less objectionable than the typical JPEG compression artifacts.  JPEG XR offers a very wide range of compression levels, including perceptively lossless or mathematically lossless compression.  Regardless of your requirements, JPEG XR probably offers a compression option that’s ideal for that scenario.

More image formats – JPEG XR supports 8bpc (bits per channel), 16bpc and 32bpc, as well as several special bit depth formats.  Pixel values can be stored as either integers, scaled fixed point numbers or full floating point values; this provides full support for numerous high dynamic range (HDR) imaging scenarios, as well as support for wide gamut color spaces.  In addition to 3-channel RGB, JPEG XR supports monochrome, CMYK and n-channel formats up to 16 independent channels.  many of these formats also support an alpha channel.   This wide range of image formats allows for dramatically better image quality and allows this single new file format to effectively replace many previous formats that were required for specific scenarios.

Advanced decoding features – JPEG XR provides progressive decoding, allowing lower resolution previews or specific cropped areas to be displayed without the need to decode the entire image.  Additionally, JPEG XR images can be cropped, rotated, flipped and resized (within certain constraints) without ever needing to decode and then re-encode the image.  That means these operations are much, much faster and no additional image quality is lost due to the additional encoding steps.

Marius Oiaga at Softpedia has a short story about the standard, and highlights the fact that it is freely available to potential implementers;

Having been approved as an international standard, JPEG XR is, of course, available for free to all interested parties. In this regard, software publishers and hardware manufacturers can easily integrate support for the new file format into their products. Of course that interoperability is the biggest barrier that stands in the way of the adoption of the new standard. But with Windows already offering support for JPEG XR, the ecosystem of software and hardware solutions built around the operating system could soon follow.

If you want to learn a little more then the press release from the JPEG committee can be found here.

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.