Before I worked on Xbox backwards compatibility, I worked on SqlXml, XQuery, and Microsoft.Xml.Query.

This is just one of those stupid implementation details, a quirk of Microsoft's XML implementation. Feel free to bug Michael Rys about it at http://sqljunkies.com/weblog/mrys/. Not only is the XML datatype his baby, but also he's currently soliciting public feedback on it.

Personally, I think the official XML Schema for XHTML should be accepted without modification. Otherwise, how can you write automated web services using a SQL backend? Do you have to manually strip out every namespace declaration involving a pre-defined prefix? Yuck!

[I hope this doesn't post multiple times. I'm having trouble with the comment tool.]

Interesting problem...

Does anyone know if SQLServer is parsing XML with MSXML 6.0, or their own internal implementation? I think the "root" of the problem is not SQLServer, but maybe MSXML (bad XML pun intended). .NET v1.1 and MSXML throw exceptions given this code as well, SQLServer might not have any control over it.

While I would agree the behavior could be improved upon, I find nothing wrong with throwing an exception when trying to declare an "xml" namespace prefix. That xml prefix is already present implicitly, so you can think of it as you are declaring it twice. The spec is clear that it should be there implicitly, but not clear on whether you should be allowed to add it explicitly. Based on the current level of understanding of the spec by 95% of the people out there, the parser would be easier to use if it just throws an error for all "xml" prefixes declared -- it is far simpler to tell people 'you don't (and can't) declare an "xmlns:xml" namespace', rather than telling them:

"'The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace' (http://www.w3.org/TR/REC-xml-names/). So you can't declare anything other than 'http://www.w3.org/XML/1998/namespace' and it's already declared implicitly so you don't have to declare it yourself, you get it for free."

For those (using .NET 1.1) that read this post down the road, if you have come across this situation and you are getting an XML doc from a system that does include the xml prefix, just create your own XmlReader, rather than letting .NET create one for you. You can either parse and validate yourself, or just create an XmlValidatingReader and pass that to an XmlDocument's Load() method. Use the ValidationEventHandler to check for and suppress that particular error. I'm of the mind that all this interop using XML is easy--you just have to know the quirks of your input, fix or ignore them, and go on from there. (It's the "unknown quirks" that scare me :) )

Finally, I find it interesting that in .NET 2.0, the behavior goes away (the parser ignores this error and lets you declare the xml namespace--if you are using the correct "http://www.w3.org/XML/1998/namespace"). However, if you use MSXML 6.0, you get the reserved namespace error. Conclusion? I'm guessing SQLServer 2005 relies on MSXML 6.0 for it's parsing. If you have problems with XML you can't control, use .NET 2.0 (within SQLServer). Create a function that you pass your external XML to, load it up, strip that xml namespace, and return the clean XML. Use the result with SQLServer as you would have normally. Slower sure, but at least it can be worked around. Maybe future versions of MSXML or SQLServer will follow .NET 2.0's lead and ignore this, if you use it correctly.

Since the XML and .NET XML teams are part of SQL Server, it doesn't really matter.

I agree it's not a big deal. It's just one of those "death by a thousand stings" issues, where some number of the schemas you try to use has an inconsistencies.

Because this is mostly only relevant when creating XML datatype columns (i.e., administration) instead of inserting data, it's not exactly a hot issue.