5 Cool Things You Must Know About the New Office 2007 File Formats

Here are the prerequisites for building the projects in this article: Microsoft .NET Framework 2.0 Visual Studio 2005 WinFX CTP (December or January - NOT February)

The new file formats are a logical progression of the XML work done in the most recent versions of Office. The last three versions have incrementally increased the XML capabilities of Office applications to a point that, today, it is possible to generate Office documents through their respective XML specifications (i.e. WordProcessingML and SpreadSheetML) without manipulating the Word and Excel object models. Given the ubiquity of XML and the XML features already included in Office 2003, the new default file formats should be viewed as a positive step forward because it places XML front and center in Office

Architecture—It's a ZIP file!
At first glance, the most obvious result of the new file formats is that they have a new, 4-character, file extension. For example a Word 2007 document is .docx, Excel 2007 is .xlsx, and PowerPoint 2007 is .pptx (see Sidebar 1 for full listing of the new file formats). In reality, any file created with these applications is just a standard ZIP file. You can change its extension to .zip, open it with your favorite ZIP file tool, and view the contents. Let's take a look at a typical .docx file.

The File Package
The entire .docx file is known as a document package. The package contains all content related to the file and acts like a file folder in the physical world. So just like a file folder can be used to store all types of content for a specific project, the package stores all content for a specific document. When opened inside WinZip, a Word 2007 package contains three file folders and one XML file as follows:

• [Content_Types].xml: An XML file listing the content types included in the document. See Sidebar 2 for listing of content types built into Office 2007.
• _rels: A folder that contains relationship information for the root level objects of the document package.
• docProps: A folder that contains the document properties. These properties are split between three files: app.xml, core.xml, and custom.xml for application properties, default document properties, and custom defined properties.
• Word: A folder that contains all the content in the Word document (i.e. Headers, Footer, Images, Fonts, Text, etc.). This folder also contains subfolders and files, as can be seen in Figure 1. The difference here versus the root, is that these files make up what is seen by the end-user.

Figure 1. The Contents of a Word 2007 Document Package's Word Folder

Parts
Take another look at Figure 1 and notice how the content of the word is split into a series of XML files. Each of these XML files is a document part that stores a specific portion of content. For example, all header content resides in the Headern.xml files, the fonts in the FontTable.xml file, the document text and WordProcessingML tags in the Document.xml file, etc. This architecture makes manipulating documents as easy as opening a ZIP file, finding the desired document part, and editing or swapping out its content. This is something I will explain in more detail at the end of the article.

Relationships
The package contains all the parts that comprise a document and the parts contain the different elements that combine to build a document. It is the relationships that glue the different parts together by defining how they are linked together, thus they are extremely important. Below is an example relationships document named document.xml.rels that specifies the relationships for the Document.XML file contained in the document package.:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<Relationships xmlns="http://schemas.microsoft.com/package/2005/06/relationships">
  <Relationship Id="rId8" Type="http://schemas.microsoft.com/office/2006/relationships
/officeDocument" Target="glossary/document.xml" /> 
  <Relationship Id="rId3" Type="http://schemas.microsoft.com/office/2006/relationships
/wordStyles" Target="styles.xml" /> 
  <Relationship Id="rId7" Type="http://schemas.microsoft.com/office/2006/relationships
/wordFooter" Target="footer1.xml" /> 
  <Relationship Id="rId2" Type="http://schemas.microsoft.com/office/2006/relationships
/wordLists" Target="lists.xml" /> 
  <Relationship Id="rId1" Type="http://schemas.microsoft.com/office/2006/relationships
/wordFontTable" Target="fontTable.xml" /> 
  <Relationship Id="rId6" Type="http://schemas.microsoft.com/office/2006/relationships
/wordHeader" Target="header2.xml" /> 
  <Relationship Id="rId5" Type="http://schemas.microsoft.com/office/2006/relationships
/wordHeader" Target="header1.xml" /> 
  <Relationship Id="rId4" Type="http://schemas.microsoft.com/office/2006/relationships
/wordSettings" Target="settings.xml" /> 
  <Relationship Id="rId9" Type="http://schemas.microsoft.com/office/2006/relationships
/theme" Target="theme/theme1.xml" /> 
  </Relationships>

This document defines nine relationships for Document.xml. For each relationship, the document defines both the content type and location of the related file. These relationship definitions are very important as part names do not persist across saves. ThusW, when Word opens a document package it uses the relationships defined in the package to locate the document parts and build out the document in the Word UI.

Cool Thing #1 Key Takeaway: The Office Open XML file formats free developers from the tyranny of the binary file format. The new files are now wide-open and accessible from any application without manipulating the Office application word models. If you are tempted to say, "Big deal! I can do whatever I want with Office files already!", keep reading.

To Learn Even More: Download (and read!) the Microsoft Office Open XML Formats Guide here.

Well they may not bring about world peace, but the new formats sure make developing solutions that include Office files a lot less stressful. No longer does a developer have to go through the Office applications just to make wholesale changes to one or more documents. Instead of needing to know the intricacies of an Office application's object model, a developer only needs to know how to peruse the contents of a ZIP file (the document package) to find and edit the desired document parts (the various xml files included in the package). If you think about it for a few minutes it doesn't take much brainpower to think of some interesting new Office-related developer scenarios.

Here are a few application ideas I thought of while researching this article:

• Project Document Generator: I am in the services business, and anytime I win a new project, I need to create several new documents: Contract, Work Order, Change Order Template, etc. With the new format, I could now build an application that allows me to select a customer from my CRM system, input a project name, and generate all required documents while I sip on my Starbucks.
• Report Writing: Office applications were never meant to be automated on a server. But by taking advantage of the new file formats, I could now generate 1,000s of Word, Excel, or PowerPoint files on the server without a worry. A good idea for an app would be a reporting application that e-mails Excel files that shows key activity metrics to insurance agents.
• Theme Library: This application would allow me to fulfill my creative design dream of selling document designs to Office users all over the planet. This application would allow a user to browse different themes from the Web or on their file system and apply them to the open document. Even better, they would be able to pick a theme and apply it to 100s or 1000s of documents at a time.

Each of these ideas is made possible (or made simpler) by the new, open file formats.

Cool Thing #2 Key Takeaway: The new XML file formats create new possibilities when developing solutions for your clients by freeing Office files from their binary format, as well as their host application's object model. In addition, Microsoft has submitted the new file formats to ECMA for standardization. Once accepted, the ECMA standardization will encourage wide-spread implementation and adoption of the file formats by non-Microsoft applications. The end-goal here is to increase Office document interoperability across platforms and back-office applications.

To Learn Even More: Download (and read!) the Microsoft Office Open XML Formats Architecture Guide here. Take a look at the ECMA proposal here. The initial draft of the proposal can be downloaded here.

Like all other Microsoft technologies, the document packages are architected to provide for extensibility. It is quite possible to include custom XML data inside the package and then reference the custom data inside the document package. The custom data will reside in a special folder named dataStore which resides in the package's word folder (or excel for Excel, ppt for PowerPoint). This means it is still possible to attach XML schemas to documents and include dynamic XML data. This also means that at any time the custom XML data is updated, those changes will be reflected in the document.

Cool Thing #3 Key Takeaway: The new file formats are extensible and can include custom data for use within the document itself.

To Learn Even More: Read Brian Jones's blog, especially this post.

If you haven't been wondering how to manipulate the new file formats with code yet, you were bound to wonder soon. The answer is that the System.IO.Packaging namespace contains all the classes you need to code against the new formats. The new Office file formats are based on the Open Packaging Conventions (as is the XML Paper Format) which will be released with Windows Vista and is part of WinFX .Windows Presentation Foundation.

Although you could use any tool that has the capability to manipulate ZIP files, you don't need them as the System.IO.Packaging namespace is designed for this purposes—making manipulating the document package as simple as opening a ZIP file, querying the relationships for the desired content types, and then adding, editing, or deleting files.

The key objects (or at least for the sample discussed next) are defined in Table 1.

Cool Thing #4 Key Takeaway: The new file formats even come with a specialized set of classes contained in the System.IO.Packaging namespace. Theses classes provide a developer with the ability to create, modify, and delete document packages.

To Learn even more: Download the WinFX SDK here. Also read Kevin Boske's blog (not many posts right now but I am sure more will follow). Kevin is the Office Programmability Program Manager so his blog is worth subscribing to.

Once you get the hang of it, the new file formats are really simple to develop against (with one minor issue—see Dev Tip below). To demonstrate, I created a sample Web page that allows a user to pick a document and then select between several options for headers and footers (see Figure 2). Once the user makes their selections, they can press the "Build Document" button causing the Web page to open the selected document and insert the desired header and footer.

Dev Tip: For some reason, the reference System.IO.Packaging does not automatically display in the Add References dialog box. This is no cause for concern, however, as this namespace is found inside the Windowsbase.dll assembly and is easily added to your project. After you install the January version of the WinFX SDK, windowsbase.dll can be found in the C:\WINDOWS\Microsoft.NET\Windows\v6.0.5070 folder.

Figure 2. Sample Web Page

Listing 1 contains the complete listing of the code behind the page.

The application logic follows this flow:

1. The click event of the Web page's button control (btnBuildIt) makes two calls to the InsertParts method included in the pages class. In each call, I specify the type of part (header or footer) and the selected document's location. The lstDocuments control provides the path of the document via its SelectedValue property.
2. The InsertParts method first determines what type of content will be inserted and sets variables for the specified content type. Next the method opens the document package and finds the location of the specified part and deletes it using a Package object.
3. In order to insert the new part, the method uses a PackagePart object to create a new document part and saves it to the same location in the package as the one deleted in step #2.
4. In the last step, the method calls the CopyStream method and passes a FileStream object that represents the content of the part to be inserted as well as a Stream object representing the blank package part created in step #3. CopyStream takes the two Stream object and copies the source into the target. I defined the target as ByRef so that any changes made are reflected in the passed object.

Figure 3. The Before and After Versions of the Selected Document

When you run the code, the original document quickly updates with my choices for header and footer (see Figure 3).

Cool Thing #5 Key Takeaway: Manipulating the new file formats in code is a simple process that does not require a lot of effort.

To Learn even more: Look for more content on the Devx Microsoft Office Professional Developer Portal, as well as MSDN.

Office 2007's new Open XML file format provides extensive capabilities to a developer. As this article has pointed out, there is a lot to be excited about and to learn.