Today I stumpled upon the SDK for Open Xml Formats and I think it is a great improvement when compared to the basic package functionality in System.IO.Packaging in .Net 3.0 . However - it seems to me that the SDK is still way too "XML-centric" and not "document-centric" at all. In the old days, when creating e.g. Excel-files via COM, you treated the created file as a spreadsheet object - meaning that you could add cells and manipulate the contents of the cells. Similarly when creating Word-documents. But in the SDK it seems you have provided strongly typed objects representing the diffent part types in OOXML and not objects to manipulate the contents of the parts. If you look in the How-to section of the SDK documentation, the article "How to: Create an Office Open XML Package by Using the Open Xml Object Model" this clearly illustrates my point.
// Set content of MainDocumentPart.
public static void SetMainDocumentContent(MainDocumentPart part)
const string docXml =
@"<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?>
<w: document xmlns:w=""http://schemas.openxmlformats.org/wordprocessingml/2006/main"">
<w:body><w: p><w:r><w:t>Hello world!</w:t></w:r></w: p></w:body>
using (Stream stream = part.GetStream())
byte buf = (new UTF8Encoding()).GetBytes(docXml);
stream.Write(buf, 0, buf.Length);
Why do I need to konw the basics of the persistance format of my Wordprocessing document when simply trying to write "Hello World!" ? In the ODF-world, the corresponding tool (AODL) is much more document-centric than this which seems way too complex to achieve a rather modest task. The code for doing this in AODL would be something like:
//Create a new text document
TextDocument document = new TextDocument();
//Create a standard paragraph using the ParagraphBuilder
Paragraph paragraph = ParagraphBuilder.CreateStandardTextParagraph(document);
//Add some simple text
paragraph.TextContent.Add(new SimpleText(document, "Some simple text!"));
//Add the paragraph to the document
Please understand that I personally like the way the SDK is structured - but at least give us a choice when creating documents. Sometimes a simple tool is better for a simple task ... compared to a complex tool for at simple task. Keeping the SDK as complex as it is now, could potentially drive developers away from OOXML and to formats with simpler tools.
Absolutely, the SDK is driving me away.
It gives me a feeling that the SDK just take care of the packaging and relationship part.
the .xml is still constructed by my own and then write it out as a part. that is where the part.getStream() for.
the SDK is not helping very much if I am generating a document.
it helps a lot if you open a document and do something to it.
but for me, a SDK that just can parse but not generate is a bit half-way for me.
True! The user has to know the specifics of WordProcessingML and SpreadsheetML if he wants to work with data extraction or loading to Office documents.
The SDK enumerable classes are just wrappers, which all of us could have written on our own.
Guys, did you figure out how to extract a VML drawing ML doc of a sheet and extract a shape out of it? I am stumped...
For every <>Part class there is a class dedicated for that part of XML which exposes the properties and child elements. for eg. WorkbookPart has a Workbook object property with which you can extract the "Sheets" child element easily ... but there is notihng of that sort for VmlDrawingPart... i.e. there is no VmlDrawing class from which I can read shape layouts and shapes... (This is with the new SDK)...
Has anyone looked into this as yet?
I second. The SDK is useless as far as generating spreadsheets goes. I have no idea why there isn't an example out there where a table from Northwind or Adventure works is dumped to an excel spreadsheet?PS. If anyonne has done this I would sure be interested.