(Updated to v2)
Due to my work as an ISV DE in MS, I had just recently been requested by an organisation to produce a small demo to demonstrate how the new custom xml parts could help them deal with an issue that is causing them trouble. More specifically, they have many client stores that produce documents based on local stored templates and client-based programs bearing logic on how to format/compile the document. As you can imagine, this architecture is difficult to maintain and more often than not causes inconsistencies between the documents produced by the various client apps.
The solution to this could be the creation of a client (a WinForm app) that would collect the data and then send them over to a WCF service. The service would produce a new docx file based on a template created by non-IT user (initially) and developers (secondary). The service would then insert all data in the new docx file (in the custom xml part) and send it back to the client as "binary" with streaming (so as not to cause unwanted overhead to the network). This way, the whole "logic" of the creation of the document is kept in the server-side (I have included a small sketch in the files to make it more clear). However, there are couple of things that need attention..
First, the people from the organisation stressed, almost from the first moment, that there are several cases where the length of the data is not known in advance: e.g. tables with arbitrary (i.e. user-defined) number of rows with data. This, of course, causes an interesting problem due to the fact that the custom xml part bearing the data, has a static schema that cannot change during runtime automatically. Therefore, the only option is to create as many content controls necessary, edit the schema of the custom xml part to add the corresponding entries and then establish the link (xpath) between them. This solution of course requires for the developer to load and deal with the content of the document and not just the custom xml part, which would have been simpler. Dispite the extra work though, it's feasible and not as complicated as one would think initially. This is shown in the demo in two ways: one by using pure xml, which inevitably results in several foreach loops, and one by using Xpath queries resulting in less and more legible code.
The second issue is the fact that the docx template might have several sections, which, depending on the options selected by the user, should or should not be displayed in the final docx. This could be implemented by using rich text content controls in the template docx, to embrace each section and then delete them as appropriate during the creation of the final docx. By the way, note that you can have other content controls within rich text content controls, and in fact pretty much anything else. This solution of course requires the developer to deal once again with the content part, which I believe in this case is understandable, since the issue is about the content/format and not the actual data. This is shown in demo with 4th and 5th section of the template. They both refer to the same topic (interest), but have deferent context. Thus, depending on what the user selects in the Loan Type field of the client application, one of the two section is deleted leaving the other to be displayed in the resulting document.
About the demo: remember to run the exes in admin mode (if you are using Vista with UAC) and unblock the port 81 from the firewall. I've highligted the content controls in the template docx to help spotting the changes in the final docx. Finally, bear in mind that the document created by the service is not deleted after sent, thus you will end up with two docs after running the demo: one random-named created by the service and one received/created by the client (called agreement).
Hope it helps,