I think Don Box's article got it right. XQuery/XPath and their data model use XSD as the basis for their type system. Yes, XML documents can be typed based on many different XSDs. But once you decide on one, the generation of the PSVI will provide you with instance type information and the schema import functionality in XQuery also gives information about the static types.
Having wild-card sections and "lax" and "skip" validation that will provide untyped and "partially" typed instances is in my opinion one of the contribution of the document/XML/XSD/semistructured data world to future type systems. The ability to move from typed to untyped data and back is one of the big features of most of the XML-based technology and the ability to get both early and late binding of types will enable different uses of the same XML data and types with the data.
Database systems that focus on performance will give the users the ability to bind types early, but will also provide dynamic retyping for the late binding use cases, although at the cost of utilizing typing for performance improvements.
In Yukon, we achieve the early binding of types by providing an XML type that is either untyped or can be typed by associating it with a collection of XSD schemata. And the late binding is achieved by allowing the CAST from one XML type to another. And we exploit the type information not only to statically type the query but also to use it in physical design and query optimizations (although, I am sure that we just scratch the surface on that aspect).
And Don: Yes the XQuery type system is based on named typing and not structural typing.
Let me try to start a discussion about FOR XML's most complex, feared, but also useful mode: the EXPLICIT mode.
When we designed the EXPLICIT mode, our goals were:
1. To provide a rowset format that could be mapped into almost any XML shape but also could be formulated by a single SQL query.
2. The rowset format was also supposed to be streamable to allow the generation of large documents.
I think the EXPLICIT mode format is highly successful in achieving these goals. There are only a few things it cannot do (arbitrary recursive part-list trees is one of them). However, the preferred SQL expression to generate the rowset format is a formidable “query from hell”. As one of the designers of the rowset format, I have all the respect for people that write and then maintain multi-thousand line EXPLICIT mode queries. But I also understand the usability, maintainability and complexity issues.
In Yukon starting with Beta1, but even more so in the upcoming Beta2, we are now planning on giving people an alternative. In Beta1, we provide you the ability to nest FOR XML queries. So if you need to generate hierarchies, you now can use nested FOR XML expressions (use the TYPE directive though to get XML). In Beta2, we will provide a new PATH mode that will give you even the ability to map columns in the same selection to attributes, elements, text nodes or even complex properties.
There will still be a few cases, where you may want to use the EXPLICIT mode (in order to generate CDATA sections or to use the !xmltext directive), but the ability to nest FOR XML AUTO, RAW and in Beta2 also PATH modes, should make the “query from hell” a much less frequent encounter.
So if you have the Beta 1 or PDC bits, I would like to encourage you to rewrite some of your EXPLICIT mode queries into nested FOR XML queries and send me some feedback. And also look at the PATH mode once it becomes available. I am especially interested in the following types of feedback: performance improvements or losses, missing functionality (no, we will not add a CDATA section generation to the PATH mode) and any other positive or negative feedback.
And yes, I know that I am writing about not yet fully publicly released software. So as punishment, feel free to send me your EXPLICIT mode issues as well :-). Although, as I mentioned in an earlier Blog entry, such questions may be better posted to SQL Server's XML newsgroup.
I just came back from an eight day trip. First a week of W3C XQuery WG meetings in Clearwater (much nicer weather than Boston that was also offered :-)), then some nice dives with Ocean Quest Dive Center together with Jim Melton (of SQL standardization fame and also member of the XQuery WG) on Saturday. We did five dives: one on the Eagle (a nice wreck at about 30m depth), and a day and night dive at Hens and Chickens, one of the nicest reef dives in the Keys (and only 6 meters deep). Since my UW Flash's battery were not cooperating, I will not have many pictures, but Jim took some as well, and I may be able to convince him to put some up on the Web.
Finally, I planned to travel to our PSS site in Charlotte to present and talk about Yukon's XML support. Unfortunately, the freezing rain in Charlotte closed the offices there so that I spent half a day in Charlotte sitting in my Hotel room doing some work. Oh well...
But now to the rant: Airline security gets bizzare. On three of my 4 flight legs, I had to go through the special security line (where you are specially searched). In fact I when through the searches four times, since it looks like that you cannot take any tool (not even a small wrench) into your hand luggage anymore. I just wonder what a terrorist would do with a wrench on the plane? Trying to take it apart? Not only that, but it looks like I (and many others) got chosen for the additional screening because we were on non-return tickets. I don't think terrorists will care about having to buy return tickets... Such profiling is just dumb. Every clever person will be able to figure out the profiling rules and attempt to fit in. The only ways to really avoid that is to either screen everybody at that level or add a random factor in. Note, I do not complain about the searches (the TSA staff was nice and helpful and took my wrench incident with humor and stride), but about the assumption that such type of profiling is actually going to achieve anything...
(Later addition: And if you read this article about the TSA No-Fly list (found at Steve Maine's blog), I fear it will only get worse. Catholic nuns...)