Archive for Interoperability

Technical Documentation Published for Office, Exchange and SharePoint

1 July 2008

Big steps today towards meeting the commitments that the company has made to interoperability with our high volume products.

You’ll find the details in a press release here;

Highlights of the actions announced today include: posting Version 1.0 releases of technical documentation for Microsoft protocols built into Microsoft Office 2007, Microsoft Office SharePoint Server 2007 and Microsoft Exchange Server 2007; posting nearly 5,000 pages of new technical documentation for the Microsoft Office binary file formats for Word, Excel and PowerPoint (.doc, .xls, .xlsb and .ppt); and making significant strides in the company’s efforts to foster more open engagement with other members of the IT community.

“Today’s actions represent Microsoft’s continued fulfillment of the commitments it made in its Interoperability Principles,” said Craig Shank, general manager of Interoperability at Microsoft. “Microsoft’s cumulative posting of approximately 50,000 pages of technical documentation on MSDN provides consistent, open access for all developers, which enhances the ease and opportunities for working with Microsoft’s high-volume products. Moreover, our work with partners, competitors and customers to engage in the technical nuts-and-bolts of real-world interoperability provides great ongoing opportunities for collaboration to address the challenges of today’s diverse IT environment.”

The press release also talks about three other initiatives that underway, the first of which is highly important to anybody doing work with the Chinese UOF standard which is getting a lot of airtime here in Asia;

  1. Working with Beihang University to develop Uniform Office Format (UOF) translators for Microsoft Excel and Microsoft PowerPoint so that users will have more options to open and save UOF documents in Microsoft Office 2007 and 2003; more information can be found on the project page on SourceForge.
  2. Designing a new translator to read from Open XML to HTML, which will provide the opportunity for independent software vendors(ISVs) to enable their customers to launch Open XML documents using lightweight browser-friendly applications; more information can be found on the project page on CodePlex.
  3. Developing PowerTools PowerShell commands for Open XML to enable IT administrators to perform document management tasks; more information can be found up on CodePlex.

Doug Mahugh has some pointers for anybody looking for additional support for the documentation that was released today;

The documentation is supported on a group of User Forums that are organized by general topic. If you have specific questions about the details, that’s the place to get them answered, and for more information about the things we’re doing to enable interoperability with Office see today’s press release or the Microsoft interop site.

As  I have said on this blog a few times now, there is still a lot of work to do, but this should be a sign that we’re committed to following through on the promises that we have made around interoperability.

Stay tuned for a lot more during coming months.

OpenXML: A Bright and Progressive Future

25 June 2008

My colleague Gray Knowlton has a post up on his blog this morning talking about our unwavering commitment to OpenXML as an essential component  of the Microsoft Office System.

Many have asked or speculated that the recent announcement of ODF in Service Pack 2 is an indication that Microsoft is quietly stepping away from Open XML. Some ask… “Is Microsoft abandoning Open XML?”

In a word, no.

That should be pretty clear.

He goes on to say;

We will continue to drive adoption of the compatibility pack for Open XML, which has now surpassed 40 Million individual downloads and gaining significant uptake in large-scale deployments. We will continue to develop and ship developer tools, translators, code samples, documentation, MSDN content and other material intended to educate people on how Open XML can help them solve specific business problems. Open XML is prominently featured in many Office Business Applications.

As to why we’re waiting for Office 14 to fully support IS29500, I think Gray did an excellent job of answering this in an earlier post of his;

Office 14 will update our support for IS29500. The timing for this might seem strange, but I do hope the rationale is clear. ODF 1.1 is a completed specification. The final version of IS29500 is not published today. While we do support a significant portion of IS29500 already, the BRM changes and other issues raised in public forums will inform us on how to best move forward with IS29500… and it gives me a little time to address the compatibility considerations that will be an important part of any file format related changes in Office. ODF has a potential upside in expanding interoperability, but as always, business continuity requirements will have a significant effect on our approach to these file format changes. Our customers will accept nothing less…

On a related note, a number of blogs are talking about the release of the 11.5.0 update for Microsoft Office 2004 for Mac this morning, which adds additional support for folks wanting to use OpenXML in that version of office.

Here are some of the changes;

Adds read/write compatibility for Open XML Format (.docx, .xlsx, etc.) files if installed with the Open XML Format Converter, Better stability and printing/page setup fixes for Word, Better paste compatibility with Office 2008 for all apps, Powerpoint fixes for stability with large documents

You’ll find the Microsoft KB article that talks about the release of the update here.

OpenXML PowerTools released to CodePlex

12 June 2008

I see Eric White is carrying details of the release of the OpenXML Powertools on his blog today.

If you want to be able to generate OpenXML documents on the server, without an installation of Microsoft Office, then this is the way to do it.

You’ll find the details on Eric’s blog by following this link;

Processing Open XML documents server-side using PowerShell is a powerful approach for creating, modifying, and transforming Open XML documents. The PowerTools for Open XML are examples and guidance that show how to do this. They consist of PowerShell cmdlets, and a number of example scripts that demonstrate the use of the cmdlets. Examples include automated word processing document and spreadsheet generation, and preparing documents for distribution external to a company, including removing comments, accepting revisions, applying a uniform theme to them, and applying a watermark to them.

His blog links to a video that explains how to install and use PowerTools for OpenXML in conjunction with the release version of the OpenXML SDK.

The three scenarios covered in the linked video are;

  • Developers who need to automatically generate documents programmatically. For example, developers may need to generate word processing documents from an XML file containing customer data.
  • IT professionals who often need to send reports, charts, and spreadsheets that summarize the state of their network, servers, computers, and more.
  • Information workers who need to prepare documents for publication outside of their company. To present a consistent appearance of documents, information workers may want to accept all revisions in the document, remove all comments, give a consistent style to the documents, digitally sign them, add a watermark, and more.

He also has a collection of other information that you will find helpful if you are looking for a way to generate or play with OpenXML documents on the server, or on a desktop without Microsoft Office installed.

OpenXML SDK v1.0 Now Available

10 June 2008

Back in March of this year, Doug Mahugh talked about the roadmap for the OpenXML SDK, an important set of tools that will allow developers to quickly develop applications that read and right OpenXML (ECMA-376) documents.

timeline

This first version of the SDK, which is available as of today, includes a set of APIs capable of manipulating Open XML Formats at the part level. This version of the SDK is a fully supported release that developers can use to build and deploy shipping solutions.

Version 2 will contain all the necessary components of the Open XML API architecture and the first CTP will be available in late summer on the MSDN download site.

Hundreds of solutions have been created by developers worldwide building on the 2007 Microsoft Office system. There are currently nearly 150 partners who have developed Open XML solutions. You can see profiles of some of them in the MSDN Partner directory, including Captaris, Intergen and Xinnovation just to name a few.

Through the Open XML SDK’s sample code and how-to articles on the programming object model, developers will be able to decrease their development time for scenarios such as:

  • Creating documents programmatically
  • Customizing parts within documents
  • Adding and inspecting custom XML within documents
  • Working with and customizing document properties

You can download the OpenXML SDK v1.0 from here, you will find more reading material on the MSDN site here, or you can participate in the MSDN discussion forums for the SDK here.

A Standard For Corporate Governance of IT

8 June 2008

Several blogs this week caught the ratification of IS 38500 by the ISO, at standard providing a framework for Corporate Governance of Information Technology.

Serge Thorn talks a little about the origins of this work, discussing how it draws from an Australian Standard, AS8015;

Establish clearly understood responsibilities for ICT (eg, ensure individuals understand and accept their responsibilities)

Plan ICT to best support the organisation (eg, ensure ICT plans fit current and future needs and the organisation’s corporate plans)

Acquire ICT validly (eg, ICT acquisitions should be made for approved reasons and in the approved way; on the basis of ongoing analysis)

Ensure ICT performs well, whenever required (eg, ensure ICT is fit for its purpose and is responsive to changing requirements)

Ensure ICT conforms with formal rules (eg, ensure compliance with external regulations and internal policies and practices)

Ensure ICT use respects human factors (eg, ensure ICT meets the evolving needs of the ‘people in the process’)

Consistent governance of information technology in corporate environments helps drive several different agendas, including assisting with delivering on the goal of interoperability between systems across diverse organizations which becomes easier as organizations become more predictable.

If you want to find out more about IS 38500 then Rod Drury provides a way to contact the ISO Chair for JTC1/SC7, Alison Holt, or you can download the standard from ISO directly by following this link.

ODF Support added to the Microsoft Office System - Additional Reading

23 May 2008

SaveAs The laziest type of blog post is one that just quotes a bunch of other people and adds little value in its own right, I tend to use this blog as a combination of a place to document some of my own views and a place to store my own notes as various events of interest take place, so I know that from time to time I’m guilty of over quoting.

This post is a combination of the two. Whenever Microsoft makes an announcement that is blog worthy there are generally two types of post that get generated, initially there is quick commentary on the announcement itself, but then shortly afterwards more considered words start to appear as people take time to think though the details.

This morning I thought it might be worthwhile bundling together some of the other posts that are out there, positive and negative.

So, here are a few of the more notable entries that are floating around this morning, for those interested in the topic of Microsoft and our support for both interoperability and document formats I think this makes for a reasonable round up of many of the views that are out there.

In each case I have pulled out a small quote from the posts I have linked, I would encourage you to follow the links and read the whole post though - there will always be more to digest than just my brief extract.

OpenMalaysiaBlog, Yoon Kit Yong - “Microsoft Office Supports ODF? AYE!”

However, I am an optimist, and I do hope that the Microsofties driving ODF support in core Microsoft applications are sincere in their intent. So far, I don’t see too much of the smarmy doublespeak this time in their press release, and I really applaud the guys for that. Although they tried to dilute the ODF subject with PDF (didnt they already have that last year?) and XPS (who really uses that?) and UOF (ni hui jiang ODF ma?), the message is quite clear.

So overall, its very encouraging. I hope Microsoft follows through with this announcement, and does not mess it up when they finally release the patch.

Before today, it used to be very hard in taking these statements seriously  …

“…  it is very important that customers have the freedom to choose from a range of technologies to meet their diverse needs.”
July 2006Jean Paoli, GM of Interoperability and XML architecture at Microsoft

… but now its definitely reads a lot less hypocritical.

Kudos Microsofties, and I wish your team and efforts well

Strong and supportive words indeed from one of the louder voices driving for ODF adoption here in the region. Yoon Kit and Ditesh (two of the principal bloggers at OpenMalaysia) frequently bring a blunt sense of reality to the way that the work that we do across the region is received by the FOSS community.

I’m pretty pleased to see Yoon Kit carrying a sense of optimism around what we’re doing here, but would encourage them both to keep our feet held close to the fire as we deliver on the promises we’re making!

NOOOXML.org - “Microsoft finally playing nice?”

A press release from Microsoft now promises native ODF support in the next service pack for Office 2007, while full support for the ISO version of OOXML will have to wait until the next major release of Office. Have they finally realized that their “format war” was a lost cause, and that the formal ISO acceptance of DIS29500 was a victory only on paper? If this is an honest attempt to play nice, it is a very welcome move. Of course, only time will tell if they will deliver on this promise, but the tone has changed dramatically, and this might actually be a good time to celebrate. We wish to welcome Microsoft to the party, even though they are very late and managed to make a fool of themselves in the process of trying to fight this outcome in every way possible. Had they only made this move a year ago, it would have saved many people a lot of trouble, including themselves. It is probably safe to assume that it was the strong opposition that forced them to the ODF table.

Pretty encouraging words from a site that was originally set up to oppose the work that we did to standardize the OpenXML file format. It is unfortunate that this is still seen as some kind of “Document Format War”. I still hold a strong view that different document formats serve different purposes. Our announcement yesterday is demonstrable of that point of view, support for ODF adds to the 20+ formats that Microsoft Office already supports, and as additional customer demand comes forth I would not be surprised to see that list continue to grow over the years.

Arnaud Le Hors - “My take on why Microsoft finally decided to support ODF”

One trick they could try and pull for instance would be to put just enough support for ODF to claim that they support it but not enough for people to really use it systematically. They could then tell customers who complain something isn’t working that it’s because ODF isn’t powerful enough, and if they want the full power of Office they need to use OOXML. That’d be a sneaky way to fulfill the ODF requirement set by customers and then force people into using OOXML anyway. Sneaky but not unlike Microsoft unfortunately. So, beware.

Reading assumptions about why we’re doing what we’re doing is always fun, I would like to think that just about everything possible is on the table and out in public view at this point, anything beyond that is just conjecture.

Maybe we’re also planning to take total control of the worlds chocolate supply, after all we do have an office in Switzerland. Next time I’m attending a planning meeting in our secret pacific island volcano I’ll ask around and see what I can uncover.

Francois Ragnet - “Microsoft opens up Office to open document formats”

Interesting to see how Microsoft have moved away from their proprietary document formats, which were previously considered as their “crown jewels”, and now focus their innovation efforts on the applications themselves. More surprising though, is the fact that Office 2007 will not support OOXML, Microsoft’s own competing format for ODF, which they recently “fast-tracked” through ISO approval. In any event, this is great news for the Future of Documents, as this is a major step towards one open document format for easy interchange between applications.

François raises an interesting point. I totally agree, innovation around office suites in general from now on will come through improvements in usability, accessibility and the role of the suite as a developer platform.

Value of an office suite will increasingly be measured thorough a combination of increased individual and group productivity and the role of that suite in integrated and diverse business processes.

Jesper Lund Stocholm - “No reason anymore to mandate anything but ODF?”

A lot of people are now spinning information about this move pulling the rug under OOXML and that ODF should be mandated everywhere - but nothing could be further from the truth. The reason why we approved OOXML still stands and the incompatible feature-sets of OOXML and ODF did not suddenly become compatible. There are still stuff in OOXML that cannot be persisted in ODF and vice versa. The backwards compatibility to the content in the existing corpus of binary documents is still a core value of OOXML and this incompatibility of ODF has not disappeared. You will still loose information and functionality when you choose to persist an OOXML-file in ODF … just as you would when persisting it to old WordPerfect formats. Insisting that having ODF-support in Microsoft Office (12 SP2) makes the need for OOXML go away is a moot point - since I am sure no one would argue to replace OOXML with TXT - simply because TXT is a supported format in Microsoft Office.

Ditto. Microsoft’s support and commitment to the OpenXML format is as strong as it ever was. As Jesper highlights for Denmark, OpenXML provides functionality that is key for customers, partners and the IT ecosystem as a whole. Support for one document format will never negate the need for another that is designed for a different purpose.

Groklaw, Pamela Jones - “Microsoft supporting ODF? –Close, But No Cigar”

I wish I could wholeheartedly applaud the Microsoft announcement about native support for ODF, but I can’t. Of course, it’s better to have native support for ODF, no matter what motives may have influenced Microsoft’s announcement, and I’m glad about that for the sake of end users. But it hasn’t happened yet. Was the word ‘vaporware’ not coined for Microsoft? In any case, I’m in the “I will believe it when I see it” category when it comes to Microsoft. They’ve earned my caution.

Fair enough Pamela, it is up to us to deliver from here, no disagreement there. Enough said. You might want to look up the word ‘vaporware’ though, it wasn’t coined for Microsoft!

Alex Brown - “Microsoft Moves to Support ODF Standard”

Whatever Microsoft’s motivations, users are set to benefit from a world in which MS Office, easily the most used office software, has aligned itself with open, documented standards. But while announcementsare all well and good the true test of Microsoft’s commitment will be found in the byte-by-byte details of the files that Office reads and writes. ODF lays down some strict rules for how these XML documents must be in order to be conformant, and software exists for testing them – I look forward on this blog to holding the magnifying glass to Microsoft’s efforts to see if what is claimed to be Standard really is so. Success will deserve praise; failure will deserve correction.

Alex has an interesting (as in genuinely interesting, not as in curious) role to play in the evolution of both OpenXML and ODF thorough his position in SC34. Ultimately ISO/JTC1 SC34 will be the working group who not only lead both the evolution of these formats, but also help the world understand what interoperability between formats actually means and how it can be best achieved.

Sheri McLeish - “Microsoft Crashing The Party: Announces Intent to Support ODF And Join Standards Boards”

Wow. Microsoft opened up today, taking a nearly 180-degree turn to announce its intent to support ODF, PDF, and XPS. Overall, this is a great, positive move. While unexpected, it’s not surprising. Microsoft has been moving toward more open standards, like with its recent DAISY XML initiative. But it’s also a no-brainer. Sticking exclusively with its competing Open XML was divisive, complicating IT’s efforts to leverage the benefits that open source XML provides.

This is back to that point around the value of Microsoft Office supporting multiple standards. What I see in Microsoft’s moves is a position that is driven by market and customer demands. Following needs of the community of companies and people who use our software seems to be the right route to take, and that is really what the addition of ODF to the list of supported formats in Microsoft Office is all about. 

Glyn Moody - “Microsoft and ODF: Has Hades Gone Sub-Zero?”

As Microsoft well knows, these markets are where most of the future growth can be expected. If they are bent on ODF adoption regardless of ISO ratification for OOXML, Microsoft will effectively be shut out of the hottest markets unless it builds some bridges (one of its favourite metaphors at the moment). Supporting this view is the fact that Microsoft’s latest announcement also includes news support for the less well-known (in the West, at least) Chinese national document file format standard, Uniform Office Format (UOF).

Again - more commentary on following customer and market demand. UOF (Uniform Office Format) is a big deal for us here in Asia, our neighbor to the north is keen to see it as the principal format for documents produced in China.

Rick Jeliffe - “Success has a thousand fathers…”

Developers/standarizers on both sides need to be whacked on their heady heads with a mackeral that Not Invented Here is not acceptable. I think people accept that until now there have been reasonable excuses: that Office could not implement ODF before it existed, that Office could not use ODF as its default format until ODF had even minimal features and completeness, that OpenFormula could be syntactically incompatible with everyone else’s spreadsheet syntax, that ODF’s graphics could cherry pick SVG without really providing actual SVG compatibility (SVG Tiny please?), and so on. (Actually, I don’t mean NIH in the sense that there absolutely cannot be multiple syntaxes or technologies for the same thing if there is some historical reason or feature difference, I am primarily talking about rejecting features merely because of their provenance.) The state of the schemas for DIS 29500 mark 1 and ODF 1.0 just reveal their level of maturity and production-level adoption, and there is nothing wrong with being an adolescent. ODF and OOXML will grow up, and they need the partisan spirit and the NIH attitude to be kept under control to do so.

I left this one until last because I think it goes to the heart of where we all need to go, and how we should think about operating from here.

Choice in document formats isn’t a war, it is a discussion, different people and groups hold different views and none can be considered wrong. Participation in the development of ODF and OpenXML provides a platform for these discussions, and a forum for resolution of the technical, political and in some cases ideological issues that need to be resolved.

I personally think we’re on a good path at the moment, but will agree with Pamela’s comment that it is principally up to us to deliver from here…

All We Need Is A Magic Wand…

28 February 2008

It has been a fun week watching the goings on in Geneva, some of the well orchestrated activity outside of the BRM has been fascinating to follow. A little like a high tech episode of The Bold and The Beautiful.

Probably by pure coincidence Google’s Open Source Programs Manager, Zaheda Bhorat, added a post to The Official Google Blog expressing a “wish” for open document standards, Google’s corporate position on OpenXML standardization.

The call to action for the post appears to be a suggestion that OpenXML needs to be “unified” or “harmonized” into ODF. A simple sounding task with a much more complex reality behind it.

It was  a topic that came up frequently during the technical evaluation period of the DIS29500 (Open XML) fast track process, and I thought it might be useful to share some personal thoughts around what I think would need to happen to achieve the (laudable) goal of harmonizing the ODF and Open XML file formats at this stage.

As I say, “Harmonize with ODF” (generally meaning unify) is a straight forward enough sounding task, but in my view the commentators on this topic often discount a lot of reality that would need to be dealt with along the way.

For the purpose of this post I need to take a simplistic approach to the issues involved, ideally any solution to the proposal to unify standards would also have to find a way to encompass the many document formats that exist in the market today, not just ODF and Open XML, but for the purpose of this text I will just address a potential path for IS26300 (ODF) and DIS29500 (Open XML).

There is probably one other expectation that needs to be set before we can begin to think about unification. The market today already has significant enough adoption of both file formats for us not to be able to dismiss any existing store of documents in either format, which means that we probably can’t take the approach of modifying one format or the other.

As a result the simple integration of the two formats probably isn’t directly possible at this stage and any effort to unify them would most likely lead to a third standard rather than the unified single standard that many workshop participants seemed to be looking for during the technical discussions around Open XML. Even if this was to become DIS26301, it would undoubtedly be significantly different from the IS26300 ODF standard, or any of the other revisions of ODF, that we know today.

Assuming that we have some clarity around which formats we are planning to unify we next have to work out where we will manage the project from. Today Open XML is maintained by Ecma, and ODF is maintained by OASIS, two different but not entirely dissimilar organizations. As part of the fast track process Ecma has proposed a joint maintenance agreement for OpenXML within ISO’s SC34 committee, maintenance of OpenXML will end up in SC34 at the end of the current process.

At this point in time OASIS does not have any such agreement in place, instead choosing to manage maintenance of the ODF format outside of the ISO process. We would need to find a common maintenance process and committee, given that this is all about ISO standardization it makes sense (to me at least) that SC34 would be the right place to do that, and giving up the current level of control that OASIS has over ODF would be a small step to take within the framework of delivering a more comprehensive single standard.

As a second step, the newly gathered committee would need to agree on design goals. Currently ODF is designed to be first and foremost an office automation document format, whereby Open XML is designed allow the document format to be used as a container for both office automation documents and a transport mechanism for other data that may be in use in an enterprise environment. The goal for Open XML in this context is that SMEs and Enterprises will be able to build their documents and related management tools into end to end SoA based business systems.

Next, now that we have the committee in place and decisions made around the major design goals, there would need to be a stage of technical unification. There are a couple of issues that would need to be considered here, nothing that would be impossible to deal with, but they would have to be cleared up.

The first is that the architectural structures of ODF and Open XML are significantly different once you open up the ZIP containers. ODF favours a simple structure with most of the XML held in a small number of files within a defined relationship.

OpenXML offers a more complex structure that exists to allow for embedded data from non office automation applications. The XML is broken up into parts of a document and the relationship between the files is created on a document by document basis, this design principal was originally selected for Open XML with the goal of offering more flexibility for scenarios such as server based document assembly applications and document security.

The second is that the XML notations within the current structures are very different as they stand today. It was pointed out in many of the technical workshops that ODF carries a very high weighting on the importance of “human readable XML”, whereby Open XML places a similar level of weighting on delivering the level of performance that is expected to be required in enterprise and data centre environments, this is achieved in Open XML by using notation that is not quite so pleasing to the human eye but is designed to be significantly more efficient for the applications that are expected to process it.

Once these two issues are worked out the committee would then need to look at the XML tags that are defined in each standard and ensure that all requirements from both standards were met. From the public discussions that I have read and participated in on this topic I think there is a general belief that this one step is the only one would be necessary.

Finally the issue of backward compatibility with existing binary documents would need to be addressed. Open XML carries a design goal of allowing the full mapping in XML for the corpus of existing binary documents, created by earlier versions of the Microsoft Office applications, that are stored by individuals and enterprises today.

The new standard would need to also carry forward the tags for the functionality that exists in these documents, only some of which currently sits in the 650+ pages of the ODF specification at this stage. I’m guessing given the increased scope that comes with the single document format goal there would also be a need to look at the binary OpenOffice.org formats, WordPerfect formats and maybe other file formats from applications that have not yet been discussed.

Assuming that partnerships and technical agreements can be reached on all of these points then the next step for the committee participants is to build this work into a document or set of documents and prepare to submit the text of the new third standard to ISO for approval.

In parallel applications would need to start adopting the new format, developers would need to be trained to understand how it works, tools would need to be build to allow testing and format manipulation etc.

All this is achievable, and in the spirit of unification the whole industry would need to be prepared to step up and deliver on this work in a mode of complete partnership and transparency.

Finally,  once this is all done we still need to look back at the other document formats that are left out of the simple scenario that I have sketched out above. This would include looking at the other existing document formats that are in use in the market today SGML, HTML, PDF/A, PDF/X and so on, some would be relevant for further unification work and obviously some would not – just another decision that needs to be made.

Again, I’ll state that these are personal views and not in anyway an official position of my employer.

Over the coming years we will see how the industry and the standards processes answer this question, assuming it really needs to be answered.

The reality is that none of this can even begin until there is a really clear understanding of the relationship between some of these document formats. For OpenXML and ODF there is a project underway in Germany to look at what these relationships are which will get us all off to a good start, delivering some real data upon which decisions and activity can be based.

This project will give everybody involved a much stronger view of what Interoperability between these two file formats looks like and how it can be delivered. Until then everything else is just supposition.

Where To Find The Microsoft Office Binary File Format Specifications

26 February 2008

A short while ago I mentioned that Microsoft had committed to releasing the file format specifications for the Microsoft Office Binary files under the Open Specification Promise and making them generally available, removing any of the complications that developers previously had to go through to get hold of these documents.

So, the only remaining question to answer is where you have to look for these documents. There are a few organizations stepping forwards to hosting and archiving these documents.

The first location is an obvious one, and it is Microsoft. The documents can be found on Microsoft.com by following this link.

There you will find;

  • Word 97-2007 Binary File Format (.doc) Specification PDF | XPS
  • PowerPoint 97-2007 Binary File Format (.ppt) Specification PDF | XPS
  • Excel 97-2007 Binary File Format (.xls) Specification PDF | XPS
  • Office Drawing 97-2007 Binary Format Specification PDF | XPS

Additionally, Microsoft also made specifications for a number of supporting technologies available, also under the OSP, these include;

  • Windows Compound Binary File Format Specification PDF | XPS
  • Windows Metafile Format (.wmf) Specification PDF | XPS
  • Ink Serialized Format (ISF) Specification PDF | XPS

The other part of the announcement about the binary file formats was the creation of a translator project on Sourceforge that would look at the translation of older Microsoft Office documents from the binary file format to the new OpenXML format.

The project is now live, and can be found here.

At the same time there are two other organizations that have agreed to host these specifications. The first of these was the British Library, below is a small excerpt from the page that they are hosted on;

The British Library believes that it is essential to archive and, where possible, provide access to the specifications of digital file formats.  These specifications are important today for people developing applications that work with digital file formats, but archived copies will be even more critical in the future when today’s applications are long obsolete.

You will find the specifications on this page on the British Library site.

The second 3rd party organization who will host the documents is the United States National Library of Congress, and here is an excerpt from their site that that again highlights the intention to preserve access to these documents for generations to come;

Listed here are selected specifications made available for downloading by the Library of Congress with the permission of their owners and the intention of ensuring permanent access to the specifications for the digital preservation community and other users. Also listed are URLs for sources of freely downloadable specifications for digital formats from standards organizations.

You will find the documents on the Library of Congress digital preservation site here.

All in all this means that the documents are available for developers who want access to them today, and are preserved for future generations by a combination of the perpetual nature of the OSP and the effort of the Library of Congress and the British Library to host this specification documentation on an equally perpetual basis…

eGovernment & SOA: Islands Become Continents

22 January 2008

The technology world is one of many buzzwords and phrases, one that you hear a lot at the moment is “Service Oriented Architecture” or “SOA” which sounds like a highly technical methodology for systems design, in reality SOA techniques can provide a very effective way of dealing with organizational complexity and divides as we work towards delivering cross departmental government services over the web.

During the final months of 1995 I found myself involved for the first time in an eGovernment project. The goal of the project was a simple one, we were tasked with providing a single “Smart Form” that would allow an individual to register as being self employed. Delivering this involved working with business processes in three government agencies, two involved in taxation and one involved in employment registration.

We looked at the challenge ahead as technologies and developers and decided that this would not be a complex system to design or build. After all, it was just a single form, digitising a single well defined process…

About two weeks into the systems analysis phase of the project the enormity of the challenge ahead started to become clearer. Simple data like a name or an address was not stored in the same way across the three agencies. The processes that we were concatenating into our single form were all being run with different service level agreements and delivering on each agreement was quite rightly something that was taken very seriously by the owners of each service. Finally it was also clear that the small amounts of addition overhead of work that would be need to run our single service just didn’t belong in any of the three agencies, and in turn didn’t have any manpower or budget in place to run it.

As a technology company the project soon began to look more like a nightmare than an opportunity, of course for the government we were working with these were exactly the types of lessons that they wanted to learn as they planned for a broader set of projects across the wider civil service.

It is interesting to look back on projects like that today and consider what has changed in the world of technology and how we might approach the project differently in today’s world. The simple answer is that these are exactly the types of challenges that information technology and large systems design principals now take in their stride.

The industry today talks a great deal about Service Oriented Architecture (SOA) which is a technical term for breaking systems into their constituent parts, and then publishing them so they can be used elsewhere while having minimal impact on the organization that provides the service.

In a Government context the advantages are clear. In a SOA world it is no longer critical that data needs to be managed in exactly the same way in every department, or that business processes need to be redesigned with the workings of the rest of the government in mind.

Today every government department can look at the services that it offers, be it licence issuance, tax collection or any other process, and then use simple web service technology to enable those services to be used by other departments or external commercial providers seamlessly.

The benefits are easy to see. Services are less complex and less costly to design and provide. With the right planning around national level architecture and data management, cross government services can be built without the need for costly and complex systems integration projects.

In some cases an agency who makes their particular line of business application available as a web service will find it being used in useful new ways by other government departments or by commercial organizations to provide services to citizens and businesses in ways that had not previously been thought about or funded.

My former team in Redmond put a lot of time and effort into looking at the right high level framework for this sort of environment would look like, the resulting work was called the “Connected Government Framework” or CGF for short. Today you will find the basic framework that the team delivered integrated tightly into many of the solutions and service offerings from Microsoft and our partners.

The lessons from this complex fifteen year journey help us deal with some of tougher issues that just about every government is facing today as they put their own plans in place for the delivery of online and electronic services. Not least of which are the still those same issues of shared service level agreements and data harmonization. Service Oriented Architectures and the technologies involved assist us in delivering complex business systems without the need to closely couple organizations or data in ways that may otherwise be less natural.

23/1/08 additional: Government Computer News this morning carries information on the release of Microsoft’s Citizen Service Platform, an announcement that was made at the Government Leader’s Forum in Berlin yesterday. Follow this link to read more;

Microsoft’s Citizen Service Platform incorporates the company’s work with local and regional governments over the past several years, and consists of templates designed to run in Microsoft operating environments for the most commonly deployed e-government services.

Microsoft will offer the initial set of online services to governments for customization and integration into their current environment later this year.

IBM & Google Now Support OpenXML(?)

19 January 2008

What a complex and confusing world we live in.

This is a really good step for all involved. IBM and Google are starting to support OpenXML, Microsoft provides access to ODF files from Office

…customers get choice, all is well with the world!

Maybe.