Hrm. I think I see the problem. The data for HTML module, historically, looked like `<html>some text <img src='/static/foo.jpg' /></html>`, because it was coming from XML, where the `<html>` tag identified the content as belonging to an `HtmlModule`. In that context, stripping the metadata off the top level tag made sense, and the data generally was valid XML unless there were bare tags (like `<br>`). When the `HtmlModule` used `self.data`, at that point it had had the `<html>` stripped off by the XML import process.

A quick scan of the data in studio suggests that that is still the form of some of the html data. However, other data doesn't fit that model (for example: `\n<html>`, and `<h2>`). This makes sense, since in studio the user has no idea that the 'correct' format is to include the surrounding `<html>` tags in the data.

As far as dealing w/ the current situation, it seems like we need to handle `self.data` that has a top level `<html>` tag, and `self.data` that doesn't. But we should get the html module to the point where it at least is internally consistent, and will write data out to xml and to mongo in a way that fixes the inconsistencies that we already have.

(The disadvantage to always dumping html into a separate file is that it makes editing the course in xml format much more cumbersome, because you end up w/ a proliferation of files containing very small html chunks)