OPC implementation test documents
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.
Comments
Anonymous
September 12, 2007
Interesting post. This sort of overview information is really helpful. Does this mean that the minimum requirement is both an "_rels.rels" file and a "[Content_Types].xml", or is the latter optional if you don't scramble the parts?Anonymous
September 12, 2007
The comment has been removedAnonymous
September 12, 2007
@Doug With Notepad Use "Save as" Choice filetype to save as "All files" Add the preferred extension to the name.Anonymous
September 13, 2007
Hey thanks, hAl! That works like a champ. I thought I tried that, but I guess not.Anonymous
September 14, 2007
It is always amusing explaining someone working at Microsoft how their own products work ;-)Anonymous
September 17, 2007
Hey Doug, do you remember when Scientific American was the best in its class? Look what it publishes now: http://blog.sciam.com/index.php?title=micro_oft_gets_spanked_twice_in_one_week&more=1&c=1&tb=1&pb=1&more=1#comments HAHAHAH MICRO$OFT GET IT?Anonymous
September 17, 2007
Yes I do, John. Scientific American linking to ... Slashdot? My father, who built shelves in my closet to hold 10 years of Scientific American (1958-1968), just rolled over in his grave. Although I sort of liked the cartoon. Perhaps we can convince the fanatics to all use cartoons going forward. It eliminates a lot of the tedium of reading their arguments.Anonymous
April 01, 2008
Like many people, I thought we'd know the official outcome of the DIS 29500 process today, but it looksAnonymous
May 26, 2008
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 buildinAnonymous
June 05, 2008
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 buildinAnonymous
June 14, 2009
In this blog post, I’m going to cover some of the details of how we approached the challenges of testing