Putting XML support in SQL Server 2000 into perspective
Many articles I have recently read start out with saying how clumsy the XML support in SQL Server 2000 is. While this is somewhat true if you want to store XML natively, we need to be fair: The reason for that is that SQL Server 2000's design goals were to take the first step in a series of steps to XML-enable SQL Server.
SQL Server 2000 focused on enabling relational to XML publishing and on providing shredding of relational data in XML form back into tables. In doing so, SQL Server 2000 addressed the main XML use case of relational database users in the 1999 to about the years 2001/2 which was to publish their existing relational data as XML and to consume structured data published as XML in order to build loosely-coupled systems. This scenario does not need to store XML natively, the primary use case for the XML data type.
Programmers have become more confident in their use of XML and now often want to store XML data that does not lend itself to the relational model and they want to store it natively. Thus, we - as well as our competitors - are adding native XML storage support in the database. For example, the ISO SQL-2003 standard defines an XML data type (which corresponds to the XML data type in SQL Server 2005).
By adding the XML data type (and the related technologies), SQL Server 2005 provides the next (but by far not the last) step in enabling full XML integration into SQL Server and thus making it into a general data management platform (together with WinFS, CLR objects, relational data etc.). More steps are forthcoming, both in SQL Server and the industry. For example, see the current activity in the ANSI/INCITS SQL standardization group, or read my book chapter in the XQuery from the Expert book :-)).
Adding an XML data type however does not mean that the SQL Server 2000 XML-relational mapping support is now obsolete. Instead, the SQL Server 2000 features are still an important aspect of providing XML support in SQL Server. Heck, SQLXML is planning to take over SQL Server :-). They may be clumsy if used to addressed the scenarios that they were not designed to address, but they still excel in their intended domain.
In summary, the step from SQL Server 2000 to 2005 has to be seen as an evolution and not a revolution. And the evolution continues!