Barring the discovery of anything that simply doesn't work, only editorial changes will be made to the latest draft of the Atom specification before it is submitted for review by the entire IETF. One thing that was added to the last draft that might raise a few eyebrows is the requirement for a wrapper <div> inside a <content> element whose type attribute's value is "XHTML". This requirement was a bit controversial, and bears some explanation.

First a little background. Here are quick examples of the three main methods of encoding the content element:

<content type="TEXT">If content's type is TEXT, it's content is plain text, with no HTML markup. &lt;this&gt; is NOT to be rendered as an HTML tag.</content>

<content type="HTML">If content's type is HTML, it's content is escaped HTML. &lt;b&gt; This sentence will be rendered bold by programs that don't ignore the HTML markup.&lt;/b&gt;.</content>

<content type="XHTML"><div xmlns="http://www.w3.org/1999/xhtml">If content's type is <i>XHTML</i>, it's content is XHTML.</div>.</content>

In this example, the div serves an obvious purpose--it contains a namespace declaration that makes the XHTML namespace the default namespace. But what if your document already declared the XHTML namespace and assigned the prefix "xhtml" to it? You could then do this:

<content type="XHTML"><xhtml:div>If content's type is <xhtml:i>XHTML</xhtml:i>, it's content is XHTML.</xhtml:div>.</content>

Now the purpose of the div is less clear. The document would be smaller, and would still be well formed XML without it, so why require it? I wrote the original proposal for requiring the div, so I should have a good answer, but Sam Ruby ended up being the one who argued for it best. His main argument was that requiring the div and specifying that it is not itself part of the content means that we can always be certain that the publisher did not intend for the outermost div inside content of type XHTML to be part of the content. If we didn't explicitly require the div and specify that it's just a wrapper--not part of the content--then when we encountered a div, we could never be certain whether it was part of the content, or just placed there to, for example, hold a namespace declaration. It's worth pointing out that adding an extra div inside XHTML content has already become common practice, so we've already been bitten by this ambiguity.

Another argument for the div is that its existence clarifies the fact that the content may not contain elements like <html>, <head>, <style>, etc., which may not appear as children of <div>. Technically, we don't need to build hints like this into the file format, but in this case, it is a nice side-effect.

There are those who argue that down the road, we'll discover the wrapper div to have been unnecessary. I for one am glad to have it, as I foresee it making my job easier when I implement Atom 1.0 support in CaRP and Grouper. I suspect that what's coming down the road is continued disagreement about the value of the div. But given that it's there, it's good to understand why.