I don't know where to comment about this (I think the policy for submissions is fine), but I noticed something about the Terms Of Use (TOU) that stopped me on the way in here.  

Down under the "Notice Specific to Documents Available on this Web Site" there is the boilerplate sentence "Use for any other purpose is expressly prohibited by law, ... ."  I've seen that many times, and I don't know why it stopped me this time, but I don't believe it is accurate (and the statement is not made under the "Notice Specific to Software and Other Materials").  

It is probably more accurate to say that no other rights are granted with addition of whatever else is found useful to say about the efforts that will be made with regard to infractions.  

I'm here, so I'm not that disturbed about the TOU, yet it seems to me that if we are going to write these acutely legalese terms they could be be more precise in what they claim and in what they grant.

Is there anyway to make the Open XML Formats more easily browsable on this site?

I actually expected the Library to have a series of links where I could click back and forth through the different specs.

This is again about software and NOT about the format. I do not want to use your platform specific api's, where is the format? How much time should I spend trying to look for them?

I want something as clear as this:
http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf

Gromerdiegrom.

For a comparison:

http://www.seweso.com/blog/2006/03/opendocument-format-alliance-vs.php  

I'm working on a high-level overview of the formats for the site, but it probably won't be up until next week.  Suscribe to the RSS feed and you'll get notice of it as soon as it's posted.  - Doug

Yes, there will be .NET samples of creating documents from scratch soon, using the packaging API.  There has been some great content shown at this week's Office Devcon the last two days, and we're pulling some of that together for the site.

- Doug

The document you're referring to is the published standard for ODF.  The Open XML Formats are not a published standard yet -- they're still going through the Ecma process, as ODF went through the Oasis process a year earlier.

The fact the Open XML Formats standard isn't out yet is a big part of the reason we're doing this site.  Various contributors will be adding content here in the days and weeks ahead that will help document the format.  Meanwhile, if you're eager to dig into the details of the format, you can always refer to the initial draft of the Ecma spec here:
http://www.ecma-international.org/activities/Office%20Open%20XML%20Formats/TC45_FD_XML_docform.zip

Also, did you look at the links above?  Many of them make no reference to any software, just the formats themselves.  For example, Brian Jones wrote an overview of many aspects of the word-processing format (that doesn't any code or tools from any platform) here:
http://blogs.msdn.com/brian_jones/archive/2006/02/02/523469.aspx

Most of the posts on Brian's blog about the formats, like this one, are directly covering the formats and not geared toward any particular language or platform or tool.

- Doug

Hey Doug, Chad Rothschiller was also there with Tristan during the schema drilldown. Tristan covered the WordprocessingML schemas, and Chad covered the SpreadsheetML schemas.

I missed that session, had to go to the office for some things.  But then, I guess that's obvious.

Sorry about that, Chad. :-)

Interesting list. I think it's worth noting that these two groups have quite different charters ...

The ODF Alliance web site says that the alliance "works globally to educate policymakers, IT administrators and the public on the benefits and opportunities of the OpenDocument Format."

The OpenXmlDeveloper.org mission statement says that the community "will serve as a technical resource for Open XML developers to submit and answer technical questions and to share tools and ideas."

Based on those words alone, I think one could safely predict that the ODF site will probably name more companies than us in the future (policymakers tend to like that stuff), while we'll probably run more source-code examples than they will (developers tend to like that stuff).

- Doug

I strongly recommend to either edit this post or delete it altogether. It is very misleading.

You said things like "Delete file (part) from the package."

It could not be further from the truth, a part does not equal a file. A part is more than that.

Besides this, the implementation is poor performance wise. There does not seem to be a valid reason to totally unzip a zip file only to be able to delete a file entry in it. Or to replicate all the files from a zip file into a new one only to add a file entry in it.

In addition to this, deleting or adding parts is a rather different job than deleting or adding file entries. This System.IO.Packaging library is already far too low-level as it requires you to play with the guts (see Kevin's code snippets), but this one really makes the cake.

My 2 cents.

Stephane,

I'll let the authors speak for themselves on some of the details, but I don't feel this post is misleading.  Yes, it's very low-level, but that's the nature of the beast: it's an example of working with Open XML Formats without the benefit of any APIs or tools from any vendor.  If that's the goal, then the simplicity of things like unzipping the whole package is probably more important than optimizing the runtime performance at this point.

And yes, a part is conceptually more than just a file, but again if ouy goal is education then this is a logical first step, getting at the files within the package.  Extending this code to manage the relationships and content types that make a file a true "part" is a great idea -- feel free to submit code for that any time. :-)

- Doug

Thanks for your answer. I'll say it differently,

If the point of this website is to gather a community around Open XML and open packaging conventions, then this article is irrelevant.

If you'd like to easily corrupt files from an OPC standpoint, files that won't open in Word/Excel/Powerpoint 2007, then this is exactly the code you are looking for.

For the record, there is a disconnect between zip entries and parts. If you fail to educate developers from the start, and insist saying it's just  ZIP, then how are they supposed to understand?

You said "Extending this code to manage the relationships and content types that make a file a true part is a great idea". Any code snippet dealing with the open packaging conventions must explicitely work with parts and their relationships, using appropriate code. It's not a "suitable extension", it's what the whole thing is about.

What to do? a low-level library *must* replicate the features of System.IO.Packaging, no matter which programming language it is written in. It does not have to expose the same object model, but it has to expose parts and relationships in a way that a developer can manipulate them without causing corruption of any sort. A library at a higher level hides parts and relationships so that a developer can directly manipulate "managed content". An example of higher-level library is the COM library of Word/Excel/Powerpoint.

My 2 cents.

The main idea of writing this block of code was to create code for creating and editing of packages using Java.  This might not be best approach or mechanism to do this, but idea was to showcase implementation of OpenXML using other technologies.

By saying Delete file I did not mean remove part, for part may be referenced in other XML files.

Delete feature was provided because I felt that there was a need, for it would provided a mechanism of removing file from the ZIP.

For Example, if in the package there was an image of type BMP that needed to be removed and replaced by an Image of type PNG there by reducing the size of the document. Utility provided a way to delete the BMP from the ZIP. But code had to be written to remove the reference of the BMP (<Default Extension="bmp" ContentType="image/bitmap" /> ) from the “[content-type.xml]”, and also have to remove the referenced BMP file from relationship file “document.xml.rels.” (<Relationship Id="rId4" Type="http://schemas.microsoft.com/office/2006/relationships/image" Target="media/image1.bmp"/>)

Please feel free to send your comments or any other alternative mechanism thought of.

Sanjay Kumar M

Hi Sanjay,

"The main idea of writing this block of code was to create code for creating and editing of packages using Java."

No that's not what the code above does. The code above creates and edits zip files. It has nothing to do with packages, and nothing to do with parts. It ignores OPC. Sorry, I don't intend to be harsh, I am only using the correct terminology.