All About Interop : Zip

DotNetZip revs to v1.6 – now with Unicode support

DotNetInterop — Wed, 15 Oct 2008 00:54:00 GMT

The v1.6 release of DotNetZip is now available. DotNetZip is the open source Zip Library for .NET, available at http://www.codeplex.com/DotNetZip .

Major new features:

Unicode support, as well as support for arbitrary code pages. Now you can build zip files that have names with Unicode characters.
Large file support. Full streaming architecture means you can zip large files without loading them into memory all at one time.
Partial Trust - for running on shared hosetd ASP.NET servers

DotNetZip is still small, fast, and the easiest .NET zip library to use. Check this sample code:

      using (var zip = new ZipFile())
      {
        zip.AddDirectory(directory);
        zip.Save(targetZip);
      }

It is 100% managed code. People love it:

DotNetZip is powerful, too: it does password-protected zip files, zip comments, self-extracting zips, zip-to-stream, stream-to-zip, and more. You can use it in any .NET app - WinForms, console app, ASP.NET page, etc. In ASP.NET, you can write a zip archive directly to Response.OutputStream as a download to the browser client. On the codeplex site, there are lots of examples and the documentation is solid.

DotNetZip is free, but is donationware. For those who are happy with DotNetZip, I am accepting donations on behalf of my favorite charity.

DotNetZip users: Please Test Unicode support (free zip library for .NET)

DotNetInterop — Fri, 19 Sep 2008 22:49:00 GMT

DotNetZip is an open-source library to allow any .NET application to read and create zip files. If you want your ASP.NET page to grab an uploaded zipfile and unpack it on the server, DotNetZip can help you. If you want to generate a zipfile from a server-based app like an ASP.NET page and send it as a download, DotNetZip can be the library you need. If you have a windows forms app or a WPF app that needs to read or write zipfiles, DotNetZip can help. If you have an agent application that watches for files to be dropped into a directory, then zips or unzips them, DotNetZip is the thing you need.

DotNetZip has been available as an open source project on CodePlex for about a year. In that time I've added a bunch of features as requested by people who are using it - support for passwords, support for stream-based interfaces, zipfile comments, the ability to remove entries from zip files, progress events for zipping up or unzipping, finer control over the use of compression, and so on.

The #1 most requested feature for the DotNetZip library is Unicode support - people want to be able to zip up files that have filenames with non-ASCII characters.

I've produced a preliminary release with support for Unicode, and I'm asking for people to try it out, test it and tell me if this does what they need it to do. The thing is, Unicode was added to the PKWare specification for zip files only about a year ago. There are few tools out there that properly support the spec. In particular, Windows XP and Windows Vista do not support the PKWare Unicode specification in the "compressed folders" feature. In Windows, if you click on a zip file that complies with the PKWare spec, you won't get what you want to get. And it's not just Windows. Most tools don't support Unicode zip files. As a result, I don't know how to test the Unicode support effectively.

Because zip tools that do Unicode are few and far between, I used a fallback approach in the library. In the latest prelim release, DotNetZip uses the IBM437 code page to encode non-ASCII characters by default. This is not in the PKWare spec, but zip files that people have sent me are using this encoding. IBM437 in zip files may be a quiet, unspecified, de-facto standard, "good enough" for many people. Of course, using the IBM437 mode, you cannot do Chinese characters, which is a huge hole. But IBM437 does cover characters with umlauts and tildes and so on, a lot of Latin languages.

And now I'm asking for your help. I'd like everyone who uses DotNetZip to try out the new Unicode and IBM437 stuff. It is available in the latest v1.6 prelim release availalble on the releases tab.

For tests:
Use the library to zip up files that have "Unicode filenames", or more accurately, filenames with characters that cannot be represented in 7-bit ASCII. This might be characters with umlauts, tildes, and so on, in addition to characters from the non-Latin languages - Hebrew, Greek, Cyrillic, and of course, Chinese.

See if it works, see if the files zip up and unzip properly. See if the files open in Explorer the way you expect. See if it works intuitively, if the library behaves the way you would like it to behave. See if the zip files can be read by other tools and libraries (7-zip or zlib or winrar). That kind of thing.

You will have to check the doc on the UseUnicode property on the ZipFile to see the options and the details of the implementation. I encourage you to try all your tests with that flag both ON and OFF - to see how it behaves and what you would prefer.

If find something that breaks, or surprises you, then please do report it. If you are really ambitious, you can write up a test case that reproduces the problem you observed and attach it to a new workitem.

The new Unicode support in the library is easy to describe, but it is hard for me to test. It is hard for me to know if I am testing the right things. I need help on this, before I can declare the unicode support useful, stable, and interoperable.

Check it out!

Create Zip files within Powershell

DotNetInterop — Fri, 27 Jun 2008 00:54:00 GMT

You can use DotNetZip library from within Powershell. It's pretty simple, fast, easy.

example:

function ZipUp-Files ( $directory )
{

  $children = get-childitem -path $directory
  foreach ($o in $children) 
  {
    if ($o.Name -ne "TestResults" -and 
        $o.Name -ne "obj" -and 
        $o.Name -ne "bin" -and 
        $o.Name -ne "tfs" -and 
        $o.Name -ne "notused" -and 
        $o.Name -ne "Release")
    {
      if ($o.PSIsContainer)
      {
        ZipUp-Files ( $o.FullName )
      }
      else 
      {
        if ($o.Name -ne ".tfs-ignore" -and
           !$o.Name.EndsWith(".cache") -and
           !$o.Name.EndsWith(".zip") )
        {
          Write-output $o.FullName
          $e= $zipfile.AddFile($o.FullName)
        }
      }
    }
  }
}


[System.Reflection.Assembly]::LoadFrom("c:\\\bin\\Ionic.Utils.Zip.dll");

$zipfile =  new-object Ionic.Utils.Zip.ZipFile("zipsrc.zip");

ZipUp-Files "DotNetZip"

$zipfile.Save()

The example above shows how to create a zip. I use it to zip up a directory containing source files, and I leave out any unwanted files or directories. Of course you can also extract a zip, view a zip, Update a zip, and so on. Anything you can do in the DotNetZip library, you can do in Powershell.

Visit http://www.codeplex.com/DotNetZip to get DotNetZip.

DotNetZip, open source library for .ZIP files, revs to v1.5 - nice ASP.NET capability

DotNetInterop — Fri, 20 Jun 2008 21:23:00 GMT

DotNetZip, the open source Zip Library for .NET, is now at v1.5.

Find it at http://www.codeplex.com/DotNetZip .

New features:

ASP.NET - save a zip archive directly to Response.OutputStream to send down to the browser client, no need to create an intermediate file on the server disk.
The ZipFile class has a progress event now, which you can hook to show progress bars.
Create self-extracting zip files - exe's that extract themselves. (requires .NET 2.0 on the target machine)
Tons of doc updates, lots of new VB example code.
Ability to update or remove entries in existing zipfiles. (Prior versions allowed you to read or create zips, but not change them).
and more....

That's all in the v1.5 library, which is now released and final. 100% managed code.

There is also a download of command-line zip tools - if you ever wanted to be able to create, read, or extract a zipfile from a command-line, or from a batch file, the utilities in the release are really handy for that. In fact I used the utilities to pack up the zip library itself, for upload to codeplex.

Also, the library is simple to use within a powershell script, so you can manipulate zipfiles in powershell. Maybe I'll post an example of how to do this in the future.

If you want some background on the Zip Library, check out my prior posts on this topic. Just for your information, DotNetZip is licensed under the Microsoft Public License, which basically means you can use it free of charge, for any purpose, but there's no warranty. Check the full terms of the license on the CodePlex site.

As always if you have questions on usage, check the CodePlex forums.

The last bit of news is that DotNetZip is now donationware. I am now accepting donations on behalf of my favorite charity. and Yes, it is a real charity.

DotNetZip now can save directly to ASP.NET Response.OutputStream

DotNetInterop — Wed, 04 Jun 2008 23:19:00 GMT

Did you ever want to zip up a file within an ASP.NET page, and then send it as a download for the requesting browser? The DotNetZip lib works within ASP.NET, and a recent update, available in the v1.5 preview release, allows you to create a zip file and save it directly to Response.OutputStream, with no intermediate file i/o, no saving the zip file to a directory on the server, no memorystreams or byte arrays to cache the content.

The code looks like this:

public void btnGo_Click (Object sender, EventArgs e)
{
  Response.Clear();
  String ReadmeText= "This is a zip file dynamically generated at " + System.DateTime.Now.ToString("G");
  string filename = System.IO.Path.GetFileName(ListOfFiles.SelectedItem.Text) + ".zip";
  Response.ContentType = "application/zip";
  Response.AddHeader("content-disposition", "filename=" + filename);
  
  using (ZipFile zip = new ZipFile(Response.OutputStream)) {
    // Add to the zip archive, the file selected in the dropdownlist.
    zip.AddFile(ListOfFiles.SelectedItem.Text, "files");
    // Add a boilerplate copyright file into the zip.
    zip.AddFile"\static\Copyright.txt", "");
    // The string ReadmeText becomes the content for an entry in the zip archive, with the filename "Readme.txt".
    zip.AddStringAsFile(ReadmeText, "Readme.txt", "");
    zip.Save();
  }

  Response.End();
}

This example assumes there is a DropDownList named ListOfFiles that contains a list of files. But of course you could get the list of files anywhere. And it goes without saying that you can add more than one file.

Simple, easy.

You need to get the 1.5 release of DotNetZip to use this new feature.

Some uses of the Ionic DotNetZip library

DotNetInterop — Fri, 30 May 2008 22:30:00 GMT

ASP.NET App that compresses a file as it is uploaded
http://professionalaspnet.com/archive/2007/11/17/Compressing-a-File-as-it-is-Uploaded.aspx
ASP.NET app to manipulate ZIP files as virtual directories or read-only resource containers.
http://www.codeproject.com/KB/aspnet/aspnetzipfs.aspx
Manipulate .DOCX files without using .NET 3.0 library code
http://conceptdev.blogspot.com/2007/03/open-docx-using-c-to-extract-text-for.html
EasyZip: Manipulate XNA Game Studio (xbox game development) content simply and easily
http://www.codeplex.com/easyzip
Tutorial (en espanol) on zipping multiple files into an archive, using the Ionic library
http://weblogs.asp.net/carloslone/archive/2008/02/12/comprimiendo-m-250-ltiples-archivos-en-un-zip-con-net.aspx
StartMenuSearch - a backport of the Vista start menu search capability. It embeds the Ionic ZIP library
http://code.google.com/p/startmenusearch/
blogcontroller; A blog application built on top of ASP.net MVC Framework
http://code.google.com/p/blogcontroller/

DotNetZip, open source library for .ZIP files, revs to v1.4

DotNetInterop — Fri, 30 May 2008 18:18:00 GMT

I have updated DotNetZip, the open source Zip Library for .NET, to v1.4.

Find it at http://www.codeplex.com/DotNetZip .

New features!! password support is here! Whoohoo!! This is PKzip (weak) encryption. Another new feature: you can now add entries into zips using content from streams. There are clearer exceptions generated in the case of errors. Beyond new features, there are a bunch of other improvements and fixes to the library, too. For example, the internal handling of zip files now uses streams for more optimal memory usage. As another example, there is now a large set of unit tests that ships with the library. As a result, reliability is significantly higher than in v1.3. Finally, the Zip utilities have been updated for better command-line parsing, more options and flexibility.

That's the v1.4 library, which is released and final.

For v1.5, I'll be focusing on Update capability - the ability to update an entry in an existing zip archive with new content, as well as the ability to Remove entries in existing zip archives. There's a preview of the v1.5 library already available on http://www.codeplex.com/DotNetZip .

As always if you have questions on usage, check the CodePlex forums.

Cheers!

DotNetZip, open source ZIP library for .NET applications, revs to v1.3

DotNetInterop — Wed, 06 Feb 2008 04:01:00 GMT

I have updated DotNetZip, the open source Zip Library for .NET, to v1.3.

[Update, 3 January 2009: DotNetZip is now at v1.7 . It includes Unicode, ZIP64, and runs on the Compact Framework. ]

Find it at http://www.codeplex.com/DotNetZip .

Some of the key ~~fixes~~ new features include: ability to read and write zips via streams, better interop with Java+Linux, better support for ASPNET (temporary file folder), support for comments in the zipfile and on each zip entry, support for overwrite. There are a bunch of ~~other~~ fixes too.

If you want some background on the Zip Library, check out my prior posts on this topic. Just for your information, DotNetZip is licensed under the Microsoft ~~Permissive~~ Public License, which basically means you can use it free of charge, for any purpose, but there's no warranty. Check the full terms of the license on the CodePlex site.

As always if you have questions on usage, check the CodePlex forums.

Cheers!

DotNet Zip Library Graduates to CodePlex

DotNetInterop — Wed, 31 Oct 2007 08:01:00 GMT

I finally created a CodePlex project for the .NET Zip Library.

Find it at http://www.codeplex.com/DotNetZip .

If you want some background on the Zip Library, check out my prior posts on this topic.

More .Net Zip Library/Utility updates

DotNetInterop — Fri, 13 Apr 2007 21:16:00 GMT

[Update: this code has been moved to a codeplex project: http://www.codeplex.com/DotNetZip . Go there for the latest source for ths .NET Zip/compression library. It does ZIP, ZIP64, SFX, passwords, unicode, and streams. All zips are fully interoperable. ]

I updated the Zip library again, this time to support the adding of fully qualified files or directories.

A couple people commented that the library did not handle fully-qualified pathnames properly. Hmmm, I guess I need to embrace Test Driven Development a little more tightly eh? The zipfile that got produced would be un-readable by Windows.

I've changed the zip library to correct that.

.Net Zip Library/Utility updates and fixes

DotNetInterop — Fri, 23 Feb 2007 06:14:00 GMT

This is an update to my zip library and utility. You can read previous entries on this here.

[Update 30 October 2007]: I moved this library to a CodePlex project. See www.codeplex.com/DotNetZip It has been steadily improved since the time of this post.

A reader mailed me to say that the Zip library did not work with some zip archives. I knew that would be true. The zip library code I had originally posted does not handle all zip files. The zip spec is pretty rich, and has a bunch of advanced features. The simple DotNetZip library I produced intially did not support them all.

But this particular reader had a pretty simple request. They needed support for the Data Descriptor field when reading a zip archive.

There's a part of the PKZIP spec that allows the compressed and uncompressed size of the files, and the CRC, to be placed after the actual compressed file data within the zip archive, in what the spec calls a "Data Descriptor". This is to support zip creation where the output stream does not support streaming. The presence of the Data Descriptor is flagged in a zip file when the "BitField" for a Zip entry has bit 3 set. The current APPNOTE from PKWare says:

This descriptor exists only if bit 3 of the general purpose bit flag is set (see below). It is byte aligned and immediately follows the last byte of compressed data. This descriptor is used only when it was not possible to seek in the output .ZIP file, e.g., when the output .ZIP file was standard output or [another] non-seekable device.

The person who emailed me also gave a zip archive that included this data descriptor, and asked "why can't your library read this zip?". Using that as a test case, I've updated the Zip library to support the Data Descriptor for reading/extracting. It will work correctly now, upon reading such archives.

Keep in mind that DotNetZip, the zip library implementation I built, is not a streaming implementation, so it will never produce (write) a zip archive that includes a Data Descriptor like this. [update: this is no longer true, as of 2008] It will produce zips that are interoperable with winzip and pkzip, as well as the Java JAR tool, etc.

[update: See the codeplex project for source code ]

Zip Library/Utility updated, works with JAR files now

DotNetInterop — Fri, 03 Nov 2006 01:50:00 GMT

I can't believe I didn't test this, but the Zip Library I built and posted a while ago was not working with Jar files. I fixed it, I think it is working now. Any problems, let me know.

[Update, 2007 January 4: Someone asked in the comments how to extract a ZipEntry to a particular folder. There is an Extract() method in the ZipEntry class that accepts a string name of a target directory as an argument. When the entry is extracted it is created using the specified directory as the root of the tree. ZipEntry's themselves may have a relative path, so the actual entry may be one or more subdirectory levels deep in the extracted tree.]

[30 October 2007: updated with latest source. Also, the zip library has graduated to a CodePlex project. See DotNetZip on CodePlex ]

WordProcessingML doc creation in Java

DotNetInterop — Tue, 03 Oct 2006 22:46:00 GMT

A while back, the OpenXmlDeveloper.org website offered an example of how to create a WordProcessingML document from within Java code. I even referenced it briefly here. Remember, WordProcessingML is the document format produced and consumed by Microsoft Word 2007, and the format will also be supported by back versions of Word via the freely downloadable compatibility pack.

I looked into that post, and found it to be pretty simplistic. Essentially, it is a guide for using the java.util.zip.* packages that are part of Java, to create a valid .docx file. The content of the document itself - the formatted text, the embedded image - in the post I referenced, all that content is manually constructed via text editors. So the post is not so much about "creating" a document, as it is about zipping up the existing parts of a WordProcessingML document.

I think a better, more thorough approach for Java is required. What is needed is a class library for Java that parallels the System.IO.Packaging namespace in .NET 3.0. Something that allows a Java application to define the parts of a document, the relationships, and so on... programmatically, much as this article describes for a .NET application.

Given the support for zip compression already in Java, and the fairly clear packaging rules for OpenXML, this extra step shouldn't be too hard to do. Once you have the packaging utility classes, then you can use the template approach I described a while ago, for WordML (the XML format from Word 2003), to create the content that gets zipped up.

What does this get you? the ability to quickly generate OpenXML docs from Java, using a higher-level API that correctly models the packaging metaphor in the OpenXML spec. In theory you would be able to do this from any Java application, whether a thick client, a server-side app, or an agent or batch job that runs with no UI at all.

Sorry, no example code, yet. I'll look into either creating a sample or finding someone else to do it. Any volunteers?

-D

.NET System.IO.Compression and zip files

DotNetInterop — Wed, 05 Apr 2006 21:38:00 GMT

DotNetZip Library

.NET 2.0 does Compression

[Update 30 October 2007]: I moved this library to a CodePlex project, called DotNetZip. See www.codeplex.com/DotNetZip. It does zip creation, extraction, passwords, ZIP64, Unicode, SFX, and more. It is open source, free Free FREE to use, has a clear license, and comes with .NET-based ZIP utilities. It works on the Compact Framework or the regular .NET Framework. It is not the same as #ziplib or SharpZipLib. DotNetZip is independent.

There's a new namespace in the .NET Framework base class library for .NET 2.0, called System.IO.Compression. It has classes called DeflateStream and GZipStream.

These classes are streams; they're useful for compressing a stream of bytes as you transfer it, for example across the network to a cooperating application (a peer, or a client, whatever). The DeflateStream implements the Deflate algorithm, see the IETF's RFC 1951. "DEFLATE Compressed Data Format Specification version 1.3." The GZipStream is an elaboration of the Deflate algorithm, and adds a cyclic-redundancy-check. For more on GZip, see the IETF RFC 1952, "Gzip".

Gzip has been done

The GZip format described in RFC 1952 is also used by the popular gzip utility included in many *nix distributions. The Base Class Library team at Microsoft previously published example source code for a simple utility that behaves just like the *nix gzip, but is written in .NET and based on the GZipStream class. This simple utility can interoperate with the *nix gzip, can read and write .gz files.

What about .zip files?

As a companion to that example, enclosed here as an attachment (see the bottom of this post) is an example class than can read and write zip archives. It is packaged as a re-usable library, as well as a couple of companion example command-line applications that use the library. The example apps are useful on their own, for example for just zipping up a directory quickly, from within a script or a command-prompt. But the library will be useful also, for including zip capability into arbitrary applications. For example, you could include a zip task in a msbuild session, or into a smart-client GUI application. I've included both the binaries and source code here.

This is the class diagram for the ZipFile class, and the ZipEntry class, as generated by Visual Studio 2005. The ZipFile is the main class.

If you don't quite grok all that notation, I will point out a few highlights. The ZipFile itself supports a generic IEnumerable interface. What this means is you can enumerate the ZipEntry's within the ZipFile using a foreach loop. Makes usage really simple. ( Implementing that little trick is also dead-simple, thanks to the new-for-2.0 support for iterators in C# 2.0, and the "yield return" statement.)

Using the ZipFile class

You can extract all files from an existing .zip file by doing this:

        ZipFile zip = ZipFile.Read("MyZip.zip");
        foreach (ZipEntry e in zip)
        {
            e.Extract("NewDirectory");
        }

Of course, you don't have want to extract the files, you can just fiddle with the properties on the ZipEntry things in the collection. Creating a new .zip file is also simple:

      ZipFile zip= new ZipFile("MyNewZip.zip"); 
      zip.AddDirectory("My Pictures", true); // AddDirectory recurses subdirectories
      zip.Save(); 

You can add a directory at a time, as shown above, and you can add individual files as well. It seems to be pretty fast, though I haven't benchmarked it. It doesn't compress as much as winzip; This library is at the mercy of the DeflateStream class, and that class doesn't support multiple levels of compression.

Hmmm, What About Intellectual Property?

I am no lawyer, but it seems to me the ZIP format is PKware's intellectual property. PKWare has some text in their zip spec which states:

PKWARE is committed to the interoperability and advancement of the .ZIP format. PKWARE offers a free license for certain technological aspects described above under certain restrictions and conditions. However, the use or implementation in a product of certain technological aspects set forth in the current APPNOTE, including those with regard to strong encryption or patching, requires a license from PKWARE. Please contact PKWARE with regard to acquiring a license.

I checked with pkware for more on that. I described what I was doing with this example, and got a nice email reply from Jim Peterson at PKWare, who wrote:

From the description of your intended need, no license would be necessary for the compression/decompression features you plan to use.

~~Which would mean, anyone could use this example without a license.~~ But like I said, I am no lawyer.

Later,

-Dino

[Update 11 April 2006 1036am US Pacific time]: After a bit of testing it seems that there are some anomalies with the DeflateStream class in .NET. One of them is, it performs badly with already compressed data. The DeflateStream in .NET can actually Inflate the size of the stream. The output is still a valid Deflate stream, but it isn't compressed as you'd like. The DotNetZip implementation works around this by using the STORE method rather than DEFLATE when data size increases. But still....

The base class library team is aware of this anomaly and is considering it. If you'd like to weigh in on this behavior, and I encourage you to do so if you value this class, use the Product Feedback Center, see here.

Office XML Formats updated

DotNetInterop — Thu, 02 Jun 2005 15:48:00 GMT

Microsoft has announced that the next version of Office (unofficially "Office 12") will deliver support for a new set of XML file formats. Calling them "the Microsoft Office Open XML Formats", Microsoft wants to produce a more compact, simpler format that is more easily programmable, more reliable, and more secure.

The skeptic is going to look at this and have a few comments:

Open!? Ha! that's funny! You Microsoft guys are always kidding around!
See? I told you Microsoft would change the format. This is the problem with vendor-controlled formats: Microsoft can make changes whenever it wants. Anyone who bet on the current XML formats supported in Office 2003 is now seeing their work disrupted. And, it will force everyone to upgrade to the latest version of Office !

I can see the reason for the skepticism. Let me comment a bit.

"Open" as it is used in this name does not mean the schema are going to be maintained by ISO, W3C, or OASIS. It means, "based on standards that are open". Based on XML, XML NS, W3C XML Schema, and others. The Schema themselves will still be "owned by" Microsoft.

The schema will be broadly accessible with a royalty-free license supporting use within any app, using any platform technology. Just as today, Java apps can produce WordProcessingML, and PHP apps could do the same thing (sorry no example available!), the same sort of thing will be possible with the formats provided in Office 12 .

As to the second comment - about the change in the schema disrupting developers and forcing upgrades. . . Patches will be shipped for back versions of Office, to enable them to deal with the updated XML formats. This will include Office 2000, Office XP, and Office 2003. These patches will be free (gratis). I am not sure if the plan is to enable these apps to produce the new formats, or only consume the new formats. In any case there will be patches.

Likewise, O12 apps will be able to consume the older format. By default Office 12 apps, when saving to XML, will save to the new format.

Some other details: Powerpoint will join the ranks of the XML-enabled apps. Cool! Imagine the possibilities of auto-generating a powerpoint app in XML! Also: you'll be able to set XML as the default file format in Office 12. Nice ! So it will no longer be a "special case" - it can be your default format. And -..... drumroll please..... the MAC version of office will also support these new formats.

Why the change? Couple of big reasons: the current formats are XMl-based, but they are kinda verbose for what they do. Lots of boilerplate markup in the XML. The new formats will simplify this. Also, there are changes to make the formats more compact (including ZIP compression), and more robust and reliable. These changes will address some of the issues raised previously by observers such as Simon St. Laurent .

Sadly, the new formats are not available yet.

There is a channel9 video on this.

Update 1: See Brian Jones' blog entry for more info and whitepapers on the new XML formats in Office 12.
[emphasized text added 2 June 2005 10ish US Pacific Time]

Update 2: this e-week article says the XML formats will be published at TechEd.
[emphasized text added 03 June 2005 15:32 US Eastern time]