It's a great tool for anyone working on debugging or developing Office Open XML documents – since we shipped it it's had over 35,000 downloads, and I personally use it all the time.

Unfortunately, as is often the way with these things, it was developed in 2010 for Visual Studio 2010, and so you need to keep a copy of VS2010 around in order to use it. Well, I'm pleased to say that in the last few weeks we've rebuilt the project so that it now works in VS2012 and VS2013, supports Visio's new VSDX format and has a few other handy minor fixes and additions. And I'm especially pleased to announce that we've published the code as an open-source project, here on GitHub (under the Apache 2.0 license). So if you have a burning desire to get it working in VS2007, have at it!

If you just want to download the new version of the Package Editor, it's here on the Visual Studio gallery.

ODF 1.2 is entering the ISO system using the PAS process, which allows extant non-ISO standards to become ISO-certified more quickly. It's the same process which was used by ODF 1.1 1.0 (ISO/IEC 26300) and very similar to the Fast Track process used for Open XML (ISO/IEC 29500). It is fast in standardization terms, but still somewhat lengthy – after a two month grace period for National Bodies to translate it into their local languages, there follows a three month ballot during which NBs may vote and submit comments. If necessary, a Ballot Resolution Meeting may be called to discuss and resolve these comments. As Rob Weir mentioned in his blog post, it's unwise to predict the speed of standards development, but it's probably probable we will see the ballot close in Q4 this year.

In 2009, Microsoft made a commitment to support new ISO versions of ODF within nine months of final publication. When we built Office 2013, we made the decision to include support for ODF 1.2 as published by OASIS because there are important improvements over ODF 1.1, such as the specification of formulas for spreadsheets early, to avoid the possibility of having to add a new file format in a service pack. We're therefore fully supportive of the ISO submission, and as a member of the ODF TC I've been working to help produce the necessary paperwork. After some months of preparation, it's great to see the OASIS standard finally make its way to ISO, and I'm pleased that we could play a small part in that process.
No rest for the wicked, though, and this means that the focus of the OASIS ODF TC now shifts towards ODF 1.3. Onwards and upwards!

One topic that often comes up is the question of how to create SpreadsheetML files from scratch. The way most people go about this is to save a blank file directly from Excel and then, using the Open XML SDK, open that template file, insert your necessary data into it and save it as the destination output file. While this works fine I can't help feeling it's a little inelegant. Why not create a file from scratch? The Open XML SDK comes with a great tool called the Reflector. You can open a file, click "Reflect code" and it'll generate the code necessary to create that file. I saved a blank file from Excel, and then opened it in the reflector. It generated 900 lines of code. Which wasn't exactly what I had in mind.

It turns out that a "blank" file saved by Excel contains a lot of data that isn't required by the standard. As well as styles, font data, margins and other layout information, it also contains many application properties and some theme definitions created by Microsoft. These are useful when you want your annual report to look great in non-Microsoft products, but they're not so helpful if you just want a grid of numbers to show up. In addition, the reflector is geared towards helping you write code to structure your workbook, not really to write large amounts of static data into it.

Nearly five years ago, my colleague Doug wrote a blog post, "CreateXlsx sample program", which walked the user through creation of a minimalist SpreadsheetML file using the System.IO.Packaging library. This was before the Open XML SDK existed, so I thought I'd write an updated version of that code using the SDK.

Without further ado, here is the code. To run it:

• Get a copy of Visual Studio 2010, and download and install the Open XML SDK
• Click File..New..Project and select Visual C# \ Windows \ Console Application
• Add a reference to the DocumentFormat.OpenXml library
• Replace the entire text of Program.cs with the following code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Spreadsheet;
using DocumentFormat.OpenXml;

namespace MakeXLSX
{
    public class MostlyGeneratedClass
    {
        // Creates a SpreadsheetDocument

        public void CreatePackage(string filePath)

        {
            using (SpreadsheetDocument package = SpreadsheetDocument.Create(filePath, SpreadsheetDocumentType.Workbook))
            {
                CreateParts(package);
            }
        }

        // Adds child parts and generates content of the specified part

        private void CreateParts(SpreadsheetDocument document)

        {

            WorkbookPart workbookPart1 = document.AddWorkbookPart();
            GenerateWorkbookPart1Content(workbookPart1);

            WorksheetPart worksheetPart1 = workbookPart1.AddNewPart<WorksheetPart>("rId1");
            GenerateWorksheetPart1Content(worksheetPart1);
        }

        // Generates content of workbookPart1. 

        private void GenerateWorkbookPart1Content(WorkbookPart workbookPart1)

        {
            Workbook workbook1 = new Workbook();
            workbook1.AddNamespaceDeclaration("r", "http://schemas.openxmlformats.org/officeDocument/2006/relationships");

            Sheets sheets1 = new Sheets();
            Sheet sheet1 = new Sheet() { Name = "Sheet1", SheetId = (UInt32Value)1U, Id = "rId1" };
            sheets1.Append(sheet1);

            workbook1.Append(sheets1);
            workbookPart1.Workbook = workbook1;
        }

        // Generates content of worksheetPart1. 

        private void GenerateWorksheetPart1Content(WorksheetPart worksheetPart1)

        {
            Worksheet worksheet1 = new Worksheet();
            SheetData sheetData1 = new SheetData();

            Row row1 = new Row();
            Cell cell1 = new Cell() { CellReference = "A1", DataType = CellValues.InlineString };
            InlineString inlineString1 = new InlineString();
            Text text1 = new Text();
            text1.Text = "hello";
            inlineString1.Append(text1);
            cell1.Append(inlineString1);
            row1.Append(cell1);

            sheetData1.Append(row1);
            worksheet1.Append(sheetData1);
            worksheetPart1.Worksheet = worksheet1;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            MostlyGeneratedClass x = new MostlyGeneratedClass();
            x.CreatePackage("c:\\chris.xlsx");
        }
    }
}

Running this code will create a c:\chris.xlsx which contains one worksheet, with "hello" in cell A1. Using this template and the reflector you should be able to build onwards to develop whatever solution you're after.

Of course, not everyone is using the SDK. In case you're generating spreadsheet files using another platform, I've attached the file that this code creates. As you probably know, you can look at the content of this file by simply renaming it to .zip and then viewing it with a normal zip file editor. It contains only five Parts, with around 32 lines of XML in total, so it should be easy enough to port this to your platform.

Code is provided under the Apache License 2.0 - I hope this is permissive enough to allow reuse in any circumstances; please get in touch if you would like to use this code under a different license for any reason.

minimalistfile.xlsx

One thing implementers of Open XML often get in touch with me about is test documents. Understandably, any implementer wants to test their implementation against some corpus of test material, but so far there’s been no straightforward place to find a bunch of documents with which to test an ISO/IEC 29500 or ECMA-376 implementation.

Well, now there is. We’ve been working with the Fraunhofer Institute for the last year or so to build and stock such a library, and I'm pleased to say that this library is now live, at document-interoperability.com.

At the core of the site is a database of PresentationML, SpreadsheetML and WordprocessingML documents. Implementers can download these documents to use in their testing, and anyone with a login can upload documents to the library to allow other implementers to test with them too.

The documents are organised into a folder structure by ML, and the downloads are available to everyone. The documents are made available under the Creative Commons Attribution 3.0 Unported License.

As well as linking to various other validation tools, the site incorporates copies of two existing validators, which implementers can use to test their own files for validity against the standard. Any files uploaded to the library are tested using these validators, and the validation results are available with the file details. Users can also vote on files, and even write comments about them.

Like any other implementer, Microsoft have an internal library of our own test documents, and over the next few weeks we'll be uploading many of those to this new public repository. I hope that, over time, this site will become a valuable resource for any implementers looking to test their Open XML applications.  If you have any comments or suggestions for parts of the site, please get in touch via the feedback form!

We had the traditional three days of meetings for WG4 and I’d say these were very productive. Aside from munching through defect reports, there were a few interesting topics that looked worthy of calling out. All the photos in here are Doug’s, unless I say otherwise.

Working out how to maintain Strict and Transitional

The text of IS 29500 specific to Office document formats is currently split into two parts – Part 1 (Strict) and Part 4 (Transitional). Part 4 is styled as an addendum to Part 1 because, originally, Transitional was a superset of Strict, so it made a lot of sense to lay it out that way. However, recently we’ve changed a few areas so that Strict actually has a larger feature set than Transitional – a good example being Amendment 1 (formerly Amendment 2) which deals with the treatment of ISO-8601 dates in spreadsheet cells. It’s difficult to describe restrictions in an addendum, and it’s even harder to describe paragraphs that are simply modified. Going forward, this problem is likely to worsen, as WG4 are not intending enlarging the feature set of Transitional with future enhancements. Should we reorganise the standard and, if so, how? We discussed a few options in the meeting, and a task force was assigned to report back with the pros and cons of the various approaches. We agreed the following day that the best solution was probably to split Parts 1 and 4 into entirely distinct texts, but we also agreed that this shouldn’t happen until such a time as a Revision of Part 1 was initiated, to avoid the duplication of the revision work. I suspect we’ll discuss this more in future meetings, as it’s likely something we’ll have to solve both for implementers and for ourselves as editors.

Changing process around maintenance of schemas

On another maintenance topic, we continued a discussion that’s been ongoing on the WG4 mailing list regarding how best to maintain the schema files. At the moment we have four sets of schemas, as we have full RNG and XSD schemas for both Parts 1 and 4. In total there’s some 2.5Mb of raw schemas, so it’s not an insignificant bundle. We’re obliged to distribute both printed and digital copies and until last week we maintained these separately, giving us some eight different schema sets to keep track of. We’ve actually found the current system to be pretty reliable, but there is widespread agreement that a better one could be found, and so we discussed this in some detail and came up with a plan.

From now on, we’ll use the electronic schemas as a master copy. Our electronic schemas are stored in an SVN repository (hosted on Assembla) and WG4 members are able to check in/out – by tagging schema changes with the relevant DR numbers, we will be able to easily derive schema changes which applied to a given DR, and we’ll also be able to consolidate the changes using standard source control tools. Whenever we are working on defect reports which require schema changes, publishing Amendments or altering the core text, we’ll integrate the necessary schema changes from the electronic copy. I was tasked with building some sort of tool to effect that, a task which I’m secretly rather looking forward to. We also agreed that schema changes would be okayed before DRs could be moved to “Last Call” by WG4, and so we have a new DR status to represent “waiting for schema”. I’m reminded of how valuable the face-to-face meetings are when we can discuss a topic at length, and finish off by agreeing on a new process and putting it in place immediately. Somehow this is often a little trickier on conference calls – perhaps this experience will all change with the onset of products like Cisco’s Telepresence, but we’re not quite there yet.

Measurement units in Strict

For some time, we have had a long discussion about a topic covered by two defect reports - DR 09-0295 [WML: gridCols measurement units] and DR 11-0001 [SML: Failures to specify measurement units explicitly]. As you can see from the DR itself there’s a long history on DR 09-0295, which runs to some sixteen pages, and it took us some time in the meeting even to fully grasp what that history was. However, I’ll attempt to summarise…

In ECMA-376, there were many attributes whose values were simply numbers, but which actually represented distances (e.g. marTop, the top margin for an HTML DIV element), which is a distance in twips. At the BRM meeting back in Geneva, it was determined that implementers should be able to specify units on these instead of relying on the default unit types – so instead of using the value “5” to mean 5 twips, they could use “0.003472 in” or “0.25 pt”. For a large number of such attributes, a union of types was created to allow both numeric values and strings with a two-digit unit specifier appended to them.

Now, things become a bit more complex. Firstly, the unit specifiers were made optional in both Strict and Transitional. In Beijing we agreed that they should be mandatory in Strict and optional in Transitional, and I wrote up the changes necessary for that. However, in Prague, we just re-agreed that they should be optional in both. Well, hey, it’s the right of a committee to change its mind. You might think that this means we can just leave the standard as it is right now! Well, you’d be wrong. DR 11-0001 points out a large number of places that appear not to have felt the benefit of the BRM changes, and it’s quite possible that there are more. Additionally, there are some places where the default units (specifically EMUs) are not actually available in the list of unit specifiers, and that seems inconsistent as well.

Murata-san, Jirka and I were tasked with establishing the possible scope of missing changes from the BRM, and once we have that data we’ll reconvene and discuss in WG4. We’re going to determine this by each attacking the standard from the angle we feel most confortable about – handily, for Murata-san and Jirka it’s the schema, and for yours truly it’s the prose. VBA, here we come.

Extra-curricular

Prague is a beautiful city, and so it seemed rude not to take a look at the local sights while we were there. Doug and I walked over Charles Bridge a few times to see if we could take some fine original shots. Given the number of giant cameras on the bridge at any one time, I think this might be the world’s most photographed landmark. If you don’t get the photo you wanted on Charles Bridge, console yourself with the fact that you can just hunt through Google image search and dig up the exact photo you had in mind, probably taken on the same day. I did take one half-decent photo (below) but some practice required, evidently.

Overall, I think these meetings went very well and I enjoyed my first time at XML Prague. We’ll be meeting again in Berlin in June – this will be more of a flying visit for me because I’ll be taking part in the 24 Hours of Lemons on the following weekend, and I’ll have to dash out at the end. Perhaps I’ll do some sort of combo trip report for the two events…

It seems like a sensible thing for me to do would be to contribute to an open source project myself, just to get a better handle on how that whole approach to software works. Apart from a few forays at university, I've so far been involved with closed-source, paid software. I spent a lot of time working in investment banking (where we'd fight bitterly with our own internal departments for source code) and then went to work for Microsoft, who are primarily closed-source software manufacturer. However, since I saw Stallman talking in London back in the mid-1990s, I've always been curious about how the open source model might work and this job seemed like an ideal chance to experiment.

But what project to work on?

One of the other things I did to, erm, increase my understanding of the working of WG4 was to buy a Nikon D40 and start attempting to take photos with it. Once I'd uploaded a few photos to my Flickr profile, I thought it might be fun to use my best photos as my Windows wallpaper. Flickr being as popular as it is, surely there was an app that did that.

There wasn't anything hugely obvious but after a bit of digging I found one, written by a gentleman named Rush Frisby. It existed as a .EXE attached to a blog post of his, and I enthusiastically downloaded it. It looked like just the thing I needed - no complicated UI, it lives for most of the time as just a taskbar icon, and off it goes and downloads pictures from Flickr. It worked very well, although it wouldn't let me pick from my own photographs (I had to use a keyword search instead) and it had a few bugs in it, mostly where the computer had no internet connection. The bugs looked pretty simple, so I emailed Mr Frisby wondering if I could fix them for him. He very kindly dug up the entire source code from his archives, and sent me it. I fixed the bugs, added a couple of features and sent it back. I was really just intending using it myself, but it seemed decent to send the changes back to Rush.

After a few more changes, I (tentatively) suggested to Rush that he open source the project. It would appear he's done more of this sort of thing, and he uploaded it to Codeplex almost immediately. Since then I've checked in a few more changes and built a setup file, so it should be reasonably usable by most people.

The app is available now at:

http://flickrwallpaper.codeplex.com/

I'd be very interested in thoughts on the app, and very interested indeed in anyone else who'd like to help develop it. I've so far not experienced any of the integration headaches that I know can exist with open source - as far as I can see I just check in changes and they magically appear on Codeplex, so it's possible I'm a project editor, or something similar to that. Or it's possible that I've misunderstood generally how Codeplex works...

More on this experience as it continues. In the meantime, Merry Christmas.

When I copy and paste this into a new document to send to my colleagues, it unfortunately looks like this:

This is because Word faithfully maintained my numbering settings, and the proceeding numbered sections are all gone. You may come across similar headaches when you want to edit a large document where the section numbering must remain constant, and you don't want to mess with it by mistake.

Well, I wrote some code to turn the numbered sections in my document into normal paragraph text. It works on numbered lists as well as numbered sections.

I'll not go into great detail about how it works, but basically it's a two stage process - I first go through the document adding the numbering text to each numbered paragraph, then I go through the document again deleting the numbering from the paragraphs. Why not do it all at once? Well, that's what I tried first, actually. You probably realised faster than I did that I ended up with a document which contained a large number of "1"s. Why not go through the paragraphs in reverse order? A fine question - I'm afraid to say that using the Word object model to index into the Paragraphs collection is very slow indeed - my guess is that when Word is asked for Paragraphs(186543) it needs to go through the prior ones first to find it. Using For Each is much faster than indexing, and I guess I can see why.

As you'll know if you run this code on a large document, it's as slow as the proverbial anyway. For thousands of pages, you may wish to prepare a cup of tea.

The code is below - as ever, if you have any fixes or changes, I'd love to hear them. Please bear in mind that I wrote this for my own purposes and it's not really been tested at all - I noticed today, for example, that it seems to remove indentation on paragraphs which doesn't matter to me but might matter to you. Please don't run this on your documents without keeping a copy of them first!

Private Sub RemoveNumberingOnAllSections()
Dim i As Paragraph, lastsaved As Date
    ' Convert all important sections to straight text (no numbering)
    For Each i In ActiveDocument.Paragraphs
        If IsNumberedPara(i.Range) Then
            ConvertNumberedToTextNoDelete i.Range
            ActiveDocument.UndoClear
        End If
    Next

    For Each i In ActiveDocument.Paragraphs
        If IsNumberedPara(i.Range) Then
            i.Range.ListFormat.RemoveNumbers
            ActiveDocument.UndoClear
        End If
    Next
End Sub

Private Sub ConvertNumberedToTextNoDelete(rOf As Range)
    If InStr(rOf.ListFormat.ListString, ".") > 0 Then
        If Left(rOf.Text, Len(rOf.ListFormat.ListString)) <> rOf.ListFormat.ListString Then
            ' Haven't done this one already
            rOf.InsertBefore rOf.ListFormat.ListString + " "
        End If
    End If
End Sub

Private Function IsNumberedPara(rOf As Range) As Boolean
    If rOf Is Nothing Then ' if the document doesn't have numbered sections, this will cause changes to be enumerated in the whole thing
        IsNumberedPara = True
    ElseIf rOf.ListFormat.ListString <> "" Then
        If Asc(rOf.ListFormat.ListString) <> 63 Then
            IsNumberedPara = True
        End If
    End If
End Function

ECMA-376 and the Flavours of ISO/IEC 29500

Perhaps I'll use that as a band name. As I mentioned in my previous post, Office 2007 uses the file format specified in the first edition of the international standard ECMA-376 as its default file format - these are the xlsx/docx/pptx files that we know and love. Office 2010 uses another standard, ISO/IEC 29500, as its default file format. These also use the xlsx/docx/pptx extensions. But wait, you say! How the heck can I open files from Office 2010 in Office 2007 then?

ISO/IEC 29500 is a direct descendant of ECMA-376. It's so direct a descendant, in fact, that ECMA-376 2nd edition is identical to ISO/IEC 29500. This is useful information for implementers, particularly because Ecma distribute standards for free, so you can get a copy of ISO/IEC 29500 by downloading ECMA-376 2nd edition from the Ecma site.

ISO/IEC 29500 has two variants: "Strict" and "Transitional". Transitional ISO/IEC 29500 is almost identical to ECMA-376 first edition, and it is this that Office 2010 uses as its default file format. Because of the similarity between the standards, files created in Office 2010 can be opened without issues in Office 2007. Office 2010 is able to read the Strict variant of ISO/IEC 29500, but writes files using Transitional. We've announced that the next version of Office, version 15, will support the creation of Strict files, but that's a story for a future blog post.

ISO/IEC 29500

I covered the organisation of ECMA-376 in my earlier post, so I'd like to give ISO/IEC 29500 the same treatment. The standard is split into four parts:

If you've ever tried to print out this standard (as I did by mistake once) you will notice that it's very large. It's not the thirty thousand pages that some telecom standards stretch to, but it's a lot of reading. As I mentioned in my previous post about Office 2007 file formats, I'd advise using the toolsets of others as much as you can rather than starting writing your read code from scratch. But, hey, maybe you like a challenge.

Office 2010 Extensions

Like any software developer, Microsoft are busy adding new features to Office with each new release, and for some features we need to find a way to store them in the file format. One of the great things about ISO/IEC 29500 is its extensibiltiy mechanisms - implementers can extend the file format while remaining 100% compliant with the standard. The bulk of the extension system is covered in Part 3, Markup Compatibility and Extensibility.

If you're not interested in Office 2010 features, you can use the mechanisms described in Part 3 to ignore them. If you do want to understand Office 2010's extensions, they're fully documented on MSDN. They're with all of Microsoft's other file format documents, at http://msdn.microsoft.com/en-us/library/cc313105(v=office.12).aspx. Depending on the type of files you're interested in reading, you'll want to read MS-DOCX, MS-XLSX, MS-PPTX or MS-ODRAWXML. Right now these are all up-to-date with Office 2010's content - when we eventually get done with the next version of Office, we will publish full documentation of those extensions at the same time as the product ships.

Implementer Notes

I mentioned Implementer Notes in my last post about Office 2007 - we've also published Implementer Notes for Office 2010 against the ISO/IEC 29500 standard. These live with the documents above on MSDN, and the exact file is MS-OI29500. I already gave a lot more information regarding how to read implementer notes in my previous post, so I won't go into detail again here.

Stuck?

If you get stuck here, Microsoft have two forums dedicated to you. The first (brand new) covers Office's implementation of IS 29500 and is something we're hoping to build up in the coming months. It's agnostic to the technology you're using to create or read the files. The second is applicable if you're using our own .NET Open XML SDK to build files - as I mentioned above I'd encourage you to use other toolsets wherever you can, and our Open XML SDK is currently the most popular approach on the Windows platform.

Summary

I realise the situation is more complicated here than it is for Office 2007, and it's much more complicated than it was for the old binary formats where all the documentation was in one place. With standards compliance comes a slightly more complex documentation situation, but the upside of using a standards-based file format maintained by ISO will, I believe, outweigh the extra effort in reading the documentation. If you remember nothing else from this article, I propose memorising the following table:

I've styled this post as referring to Office 2010, but in reality this approach should stand you in good stead for many versions of Office into the future, as you'll be using variants of the above three documents for a long time to come.

The first question customers ask when starting to read and write Office files is: Where is the documentation for the Office 2007 and 2010 file formats? It’s on MSDN, with the rest of your file format documentation, right?

Well… wrong. Let me start with Office 2007 first, and I’ll cover Office 2010 in the next post. I do this to build my audience into a frenzy of excitement. It’s like Eastenders.

Office 2007 and ECMA-376

Office 2007’s default file format is not something that belongs to Microsoft – it’s actually an international standard, ECMA-376 (also called “Ecma Office Open XML”). Microsoft were very active in the creation of this standard, and we’re still the biggest implementers of it, but the documentation of this standard is owned and controlled by the standards organisation Ecma International, not Microsoft, and so it doesn’t appear with our file format documentation on MSDN.

The good news is that ECMA-376 is freely available and almost everything Office 2007 writes is covered by that standard. The standard is split into five parts:

The standard contains the documentation for all three spreadsheet, wordprocessing and presentation formats. In reality they are very similar – the packaging and extension mechanisms are almost identical, and so it makes sense to have them in the one standard. Once you get into the details in Part 4, they’re broken up into separate sections.

If you’re starting with nothing, you might have to read all of the separate parts of the standard. You can implement code to read and write files from scratch, of course, but as always I’d encourage you to build on the shoulders of giants and use some of the existing tools to read and write files. Eric White has done a number of blog posts about such tools, so that's a good place to start. If you do build upon stuff created by others, the chances are Parts 3 and 4 will be where you spend the most time as someone else will have done the grunt work on the rest of it.

Implementer Notes

With our other file formats (XLS, DOC et cetera), there’s just one document to read. This is because Microsoft is the keeper of both the product and the documentation – if we find a discrepancy, we’ll change the documentation to fix the error or add a footnote pointing out the product behaviour. Because ECMA-376 is an international standard, we aren’t able to simply edit it, and so we maintain a second document explaining where Microsoft’s implementation differs from that standard. These are our “implementer notes”, and they’re freely available here. Developing these types of notes is a common courtesy for implementers of standards - for an example in a completely different world, here are British Telecom's "Supplier Information Notes" about aspects of their xDSL implementation.

If you’re generating ECMA-376 documents for consumption by others, we’d encourage you to create some similar notes for your implementation, so that your customers can interoperate with you easily too.

ECMA-376 fairly closely represents what Office 2007 writes, and I have to admit that it’s been quite a while since I ever had to look up an implementer note when delving into files created by Office 2007. However, if interoperating with MS Office is your top priority, you should take a look at the implementer notes before relying heavily on a feature. One example that I’ve mentioned in the past is grouping and outlining on spreadsheets.

ECMA-376 allows up to 256 levels of these, while Office 2007 will only use seven or fewer. This behaviour is documented on page 276 of the implementer notes:

The standard defines the outlineLevel attribute without specifying its maximum value. 
Office specifies the outlineLevel attributes maximum value is 7.

If interoperability with Office 2007 is a priority for you, it would be wise to read the implementers’ notes for each ECMA-376 element you’re thinking of using before doing a lot of development work.

The standard, ECMA-376 1st Edition, is now frozen in time and will not change. If Microsoft find any other ways that our implementation differs from that standard, we’ll publish new implementer notes, but we can never change the version of the standard that we targeted to be compliant with. In some ways this is great news for you as it means you’ll never have to update your implementation in order to remain conformant to the standard. However, to interoperate with Office, you’ll need to keep an eye on the implementer notes in case there are any changes. In reality we think we’ve found most of the notes we’ll need for Office 2007, but every so often we do find a bug that needs a new one.

But what if you want to interoperate with Office 2010 features? Well, you’ll have to wait for the next post. How am I doing with this cliff-hanger thing?

"Most Productive Meeting Ever"

Well, perhaps not the world record holder, but the convener remarked on the final day that this had been WG4's most productive meeting ever. I've only been to four of them, but I'd certainly agree that it's the busiest one I've been to. Towards the end of the third day we were rushing to try and get through the agenda items, and we only covered around half of the defect reports (DRs) that I'd hoped to discuss. Looks like we'll be heading for a few of WG4's most productive conference calls in the coming weeks.

Meeting Content

I was very interested to see Murata-san's presentation on the issues with internationalisation and Part 2 (OPC). I felt like it framed the conversation well for me - there was some work done at the BRM to internationalise Part 2, and it looks like there's still polishing to be done in that area. I was also very pleased indeed that Suzuki-san, a Japanese font expert, was there to talk through several font DRs that we have. Suzuki-san is a well-known contributor to a bunch of print-related open source projects (with GhostScript probably being the most famous one) and is also an expert explainer, so with his help we managed to resolve a bundle of these DRs.

We spent a lot of time working through the open defect reports at this meeting. I'd been working for the last few weeks on writing up the required changes for many of them, and I pledged at this meeting that, at each WG4 face-to-face meeting, I'd try and be current with the un-written-up defect reports which were opened before the previous meeting. When we meet in China in December, I'll have written up the changes for any we had open in Tokyo that were waiting for Microsoft input, and I'll keep this rolling forward. Obviously I'll also try to keep on top of any that appeared in the interim period, but I'll at least set this baseline so we can get through a few of the oldest DRs.

Amendment 2: Improvements to ISO 8601 Support

At the Plenary, a few changes were approved to Amendment 2, the Amendment which will improve ISO 8601 date support in IS 29500. While working on this, Gareth Horton and I have broadened the scope slightly to cover a new change to Part 4 (that being the removal of ISO 8601 dates) and a few other alterations in Part 1 (most notably the removal of the leap year bug, which was not covered in the original Amendment). We knew we were going to take this scope change to the plenary and we already have draft text for the newly-approved Amendment. We've had an enormous amount of help from WG4 in writing and reviewing this Amendment - Jesper Lund Stocholm, Rick Jelliffe, Makoto Murata, Norbert Bollow and Jirka Kosek have been a great help during our review period with WG4, and most recently I've got some great feedback from Kohei Yoshida, a key spreadsheet developer on Novell Open Office. Gareth and I have committed to circulate a final draft around WG4 before November 1st. Feels good to be near the end of the tunnel, and on a personal level it'll be great to be a project editor of a finished SC34 project.

Creating More Defect Reports

As we all know, IS 29500 is a lengthy standard. There are indubitably defects in it that nobody's found yet, and we brainstormed for a while at the WG4 meeting about how we could go about finding some more. We talked about comparing the normative XSD schema with the informative RNG one; looking for long recurring strings in the text and reviewing those areas; generating a concordance and looking for rarely-occuring words which might be signs of trouble. I think we had a really interesting discussion about the topic, and I'm going to spend some time looking into actually getting started on some of those "bug-fixing" missions.

Study Groups Abound

Two of the hottest topics in SC34 at the moment are EPUB (the current de-facto standard for electronic book publishing) and ZIP (the file compression format). For both of those, SC34 has decided to do some more thought - for EPUB this comes in the form of an ad-hoc study group, and for ZIP it comes in the form of a study period during which some experts will work out how best to proceed. WG4 has also agreed to embark upon the early stages of a revision to Part 3 (MCE, the part which specifies how implementers can add their own custom features to the format). We agreed that we wouldn't break any existing implementations in taking on the revision, and a study group are off working on a scope description which will be circulated around WG4 soon.

Office "15" Strict IS 29500 Support

As you probably know, we announced some time ago that we would support saving the Strict variant of IS 29500 for Office "15", the version after Office 2010, which will appear some time in the next few years. We're right at the beginning stages of development of that product, so I took the opportunity to talk with WG4 about how they'd expect our strict support to behave. For me, the most interesting part was how we resolve a dichotomy we have: We want to be as pure as we can be in the data we put in strict files (so not too much MCE), but we also don't want to discard anything when a user saves as the default file format. We had some interesting talks around this in WG4 and I may do a future post outlining some of our more detailed thoughts.

Mount Fuji

After the UOML BRM meeting on Saturday, Jirka and I left town to head for Mount Fuji. How nice to get into the peaceful wilderness of the mountains after a hectic week in the centre of the metropolis!

How great indeed. They say that Mount Fuji is the world's most climbed mountain, and now I can see why. There are probably twenty rudimentary mini-hotels on the way up, and a quite astounding amount of building work going on in avalanche protection and such. If you ever find a spot on Mount Fuji where you can't hear a diesel engine, the chances are you can instead smell a chemical toilet.

We had a good time - it was an interesting climb, but not quite what we had in mind. It made us wonder whether it would be fun to try and reach the highest point in each country hosting SC34 meetings, until we realised what our next target would be.