Some details on the SQL XML DataType and Compression
A frequent question on one the newsgroups I frequent is "why, when I store and XML document in a column doesn't the amount of space used exactly match the size of my document?" Usually, there's some thought that because less space is consumed than expected that part of the XML has been lost in flight to the database. Rest assured that's usually not strong. What you are actually seeing in these cases is a compression of the data during storage.
But that's not "compression" in the sense that we might normally think of it: Like RLE or LZW. Rather, when XML data is stored inside of SQL Server 2005, the internal representation is not an exact image of the source XML. In fact, the XML is "shredded" into a other form (what that is isn't relevant to this discussion). As part of that process, XML QNames are tokenized. The more repeating QNames you have, the greater this "compression effect" is.
Now, there are times where the "compression effect" is just the opposite. Suppose your XML text node data was composed mostly of 1-byte character strings. When that goes into storage, it takes up two bytes: Remember -- all XML string data is stored in UTF-16 encoding today. Another common case is when you have typed XML. Suppose you have a node typed as xs:double, but it contains the string value "1." Well, in an typed scenario, the amount of space taken up is the size of the type class: 8-bytes in this case, rather than the 2-bytes it would take to store "1."
Mad props to Eugene Kogan from the SQL Server Team for enlightening me about this.