It is good to be reminded just what RELATIONAL means.

XML is an example. Your piece of XML will itself have columns and rows, so it is logically a table (relation). By wrapping it up as a string and storing it in a column, you are logically nesting tables.

You database engine may allow you to step outside the bounds of relational principles this way, but the price you pay is that nicely interchangable tools that have developed due to the consistency of the relational model, like report writers for example, will not work with such arbitrary models. Not that XML itself cannot be recognised as relational data, its where its usage breaks the rules, such as nesting tables.

XML in particular is better thought of as a TRANSPORT for relational data, and as such you want translators to/from XML and native tabular protocols. I think SQLServer got it wrong. Instead of SELECT..FOR XML, there should have been an alternative type of CONNECTION that used XML as the transport, and every SQL statement should be independent of which type of transport it will use. In ADO, XML would be a subclass of Recordset. I hate to think that all the stored procedures that existed on one database I worked on, would all need to be cloned for an XML version.