In my presentation at TechEd SEA yesterday, I explained the importance of writing code against the relationship structure of an OPC package instead of hard-coding URIs that point to specific part names in specific folders. That’s a key concept for building flexible Open XML implementations that interoperate with other implementations: follow the relationships, and ignore the part names and locations, which may vary between different implementations.
The attached ZIP file contains three sample documents that demonstrate this principle. I’ve included a DOCX, XLSX, and PPTX that have start parts named whatever.xml, and don’t include the word/xl/ppt folders that Office uses for storing the start part. So the content of these documents is physically different from what Office would generate, but they’re valid Open XML documents that conform to the spec.
Here’s the root folder of the ZIP package for each of these sample documents:
If your Open XML implementation is written against the spec, it will open these documents just fine because you’re just looking for the officeDocument relationship type to find the start part, and the name and location of that part don’t matter at all. But if an implementation is written against something other than the spec (oh, say, Office’s implementation), then your app won’t open these documents.
You can use these documents to test an Open XML implementation for conformance to the rule that it’s relationships and not URIs that define the structure of an OPC package. And in case you’re wondering, yes, Word 2007, Excel 2007, and PowerPoint 2007 open these files just fine:
If you find another implementation that doesn’t work with these documents, you might want to let the developer know. When you’re just working with documents created in Office, these details don’t matter, but the pace of delivery of new Open XML implementations is accelerating, and we all need to follow the spec to deliver on the interoperability that it enables.