Deck from my XML 2005 presentation available

I’ve had a number of folks who attended my session at the XML 2005 conference ask me if the deck was available online. I thought it was posted, but I wasn’t able to find it anywhere so I decided to post it myself. You can go have a look here:

Of course, the deck isn’t nearly as interesting as the demos. If you watched my PDC presentation, you can see a number of the same demos (although at the XML 2005 conference I was using Beta 1 and the demos looked better).

After taking Thursday and Friday off for Thanksgiving (I hope those of you that celebrate Thanksgiving had as good of a meal as I had) I figured I’d try to get some work in today, which of course usually leads into me looking at this blog. There are a bunch of comments from the previous two posts that I’ll try to get to. I’m also noticing that the folks who are big ODF fans are pushing on other areas now that the openness and licensing details are getting sorted out. There are of course a number of individuals and a couple companies that have really big stakes in that format so you can expect to hear a lot of noise over the coming months. I’m glad the discussions are shifting more into the technical details of the formats and the use cases, as that’s what I really enjoy talking about. I look forward to making that shift back into the more technical details which is what most people reading this blog where interested in anyway (but as I said I will also try to get to all the questions from the previous posts). Sorry we had to spend so much time discussing the licensing over the past few months.


Comments (13)

  1. Mario Goebbels says:

    Maybe not exactly the best post to ask this in, but still. You’re not a beta engineer (who didn’t exactly get my bug/wish) but actually the PM, so:

    Are you guys going to improve the Zip compression algorithm you’re using? I’ve noticed that I can squeeze another 15-20% out of the filesize (if it’s mostly text/XML) at maximum setting in WinRAR.

    It’d be cool if the Office applications had similar compression efficiency. If the weaker compression has a reason, a checkbox for maximum compression would be nice, for redistributing documents and such.

  2. SlashDotJunkie says:

    Mario, it was a joke, right? WinRAR maximum compression mode uses solid archive (think, tar+gzip), and it is very, very slow. Moreover, unlike Zip, WinRAR has no OS and developer support.

  3. Kailash says:

    Requesting more frequent posts!

  4. Mario Goebbels says:

    I’m talking about generating regular Zip archives with WinRAR. I wasn’t talking about the actual RAR format, just the archiver application.

    Unzipping the documents and then rezipping them with WinRAR at Zip(!) Maximum gives me smaller documents than what Office generated.

  5. S. Colcord says:

    Relating to the technical details, Groklaw has posted a comparison of DOCX and ODF at <;

    Obviously, this is not likely to be an unbiased comparison. However, it presents three arguments favoring ODF:

    1) It provides examples of how ODF uses existing standards, such as XLink and the Dublin Metadata Core, where DOCX uses a (presumably) proprietary structure to accomplish the same purpose.

    2) It shows places where ODF does a better job making a clean separation between content and style.

    3) It shows examples of ODF being easier to read than DOCX.

    I would be very interested in reading a techinical reply to these criticisms. Do you think that they are fair comparisons?

    A recurring point of suspicion about Microsoft is that it avoids using existing standards in order to minimize interoperability and gain maximum leverage from its monopoly. The most effective counter to this accusation is to demonstrate that there was a clear technical need to do so. Can you present such a case?

  6. Martin Bryan says:

    Thanks for posting the deck Brian, but that does not include the demos, and the link on the PDC page no longer works. I would dearly love to walk through those demos more slowly than you were able to do them at XML 2005!

  7. BrianJones says:

    Hey Martin, what happens when you follow that link? It still works for me, so I’m wondering if there is some other issue going on.

    One thing that might work better is to go follow this link:

    (You’ll need to wait for all the material to download before it will play).

    For those folks that are on Beta 1, I’m also going to start posting some of the demo files that I used so you can try it out yourself.

    S. Colcord, I’ll take a look at those points and give a reply. I’ll probably just do it in a seperate post. I wanted to avoid getting into a discussion about which format is better though, because I think it’s fine having two formats and I don’t want to take anything away from the work that Sun did. I don’t think the Excel and Word should have the same format, and if StarOffice and MS Office have different formats that’s fine too. I think the key is that the formats are open; well documented; and there are tools available for working with them. Then people can build filters for going between the two.


  8. Stephane Rodriguez says:

    Brian, since you are tech savvy, would you mind checking that article :

    The question is, the XML schema matters yes or not?

    If not, why is XML so much better than the binary format? Why should anyone bother then?

    If yes, why don’t you ship a couple funky XSLT transforms along with Office 2006 (preferably accessible from the SaveAs button (and I want fries with that)) and get away with all those MSXML/ODF troubles?

  9. Pete says:

    Hi Brian,

    Sorry, came late to the party and missed all these interesting posts.

    Good news that Microsoft is opening up its formats. However, I was reading through the materials on the new formats, and one thing bothered me a bit.

    The way I’ve understood is that file saved in the new XML formats is stored in a container file. This container file will then contain the main document (the XML document), as well as other parts such as the VBA apps, images, charts, etc. all separated from the main XML document.

    My question is whether Microsoft is opening up the whole container format, or just the XML part of it? It is probably my inexperience in these matters, but I got a little concerned especially because I understood that the container docs are reliant on WinFX APIs, and to my understanding WinFX is only present on Windows. Doesn’t this make it a little difficult for us poor Linux folks to try to implement support for the complete MS Office 12 files (i.e., the handling of the container format, and all the parts contained in the format)?

    Thanks Brian for letting me know. Good blog, and great to see that MS is working hard on making Office 12 the best one so far.

  10. Stephane Rodriguez says:

    "container docs are reliant on WinFX APIs"

    Actually i don’t think it’s mandatory to use these, otherwise the Mac version of Office 2006 would be in trouble. As long as you are using an API which conforms to it, you should be covered.

  11. Darryl Hover says:

    It is my understanding, Pete, that the APIs are provided to make it "easier" to work with the document formats. As long as you have a zip library available, you can open and save into the containers. And as long as you know the schema, you can use your programming skills and language of choice to do whatever you need to with the individual parts (or collections of parts).

    Personally, I’ll be using PL/SQL in an Oracle (sorry, Brian :)) database server to create documents on the fly. Can’t wait.


  12. BrianJones says:

    Hey Darryl, no problem on the choice of database (although my friends over in SQL may differ in that view). I’m actually glad to see that you’ll be using a non-MS product, which helps show how it’s an open format.

    The reason I’ve talked to the WinFX APIs is just that they provide an easier way of accessing the files (as you’ve said). The conventions we use for storing our files in ZIP are all documented (it’s just ZIP and XML), so any ZIP library and XML parser will do. We just wanted to provide the APIs to make things even easier.


  13. orcmid says:

    " … I think it’s fine having two formats and I don’t want to take anything away from the work that Sun did. I don’t think the Excel and Word should have the same format, and if StarOffice and MS Office have different formats that’s fine too. I think the key is that the formats are open; well documented; and there are tools available for working with them. Then people can build filters for going between the two."

    I’m all for that. I think that’s what we need the most right now, and I’m delighted to see that approach.

    It is also a great way to get some "ground truth" on difficulties of faithfully interconverting and how more alignment can be reached in the future, as appropriate. For example, I don’t think it is as simple as running XSLT from one format to the other [;&lt;).