Hi Frank,

It all depends on what you want to do with it.  For instance, when combined with some of SQL Server's other new features like HTTP Endpoints, etc., you can potentially "eliminate the middle man" and send XML documents directly to SQL Server for shredding via Web Methods.  Done right, this could potentially eliminate network traffic, cut down on development time, and eliminate potential points of failure in the system.

Consider sending a 100 MB XML document to a .NET app, an app who's sole purpose is to shred the XML and send it to SQL Server.  You have a potential point of failure between the front end and the .NET app in the middle, and another potential point of failure between the .NET app and the SQL Server.  You also have the additional overhead of opening and maintaining a SQL Server connection while transferring the data from the .NET app to SQL Server, and the additional bandwidth involved in effectively sending the data over your network twice (once from the front end to the .NET app and once from the .NET app to SQL Server).

By setting up an HTTP Endpoint and sending the XML data directly to SQL Server for shredding you eliminate one potential point of failure, remove the additional overhead of opening and maintaining a connection, and only have to transfer your XML data once.  Of course this is just one example, which might or might not be applicable to your particular situation.

Also keep in mind that not all data is best represented relationally.  SQL is great for highly structured, highly "regular" data.  XML is often better at representing semi-structured and hierarchical data (granted CTE's in SQL do help a bit with the hierarchical data).

Thanks!