Via a post on Don Box's weblog I noticed that quotes from my weblog have been used to further an incorrect assumption about Microsoft's technological direction with regards to XML technologies in the future versions of Windows (aka LongHorn) and other products.

Steve Gillmor writes

A key inducement for migrating to Longhorn is WinFS. FS means future storage, and the scheme is a new file storage system that will make it easier to store and find data. Instead of leveraging the XSD standard, Microsoft designers rolled a new schema language to handle WinFS' new capabilities
...

Clearly, Microsoft wants developers to create tomorrow's applications on Longhorn and WinFS. Right?  So why did Dare Obasanjo, program manager for .Net Framework XML schema technologies, have this to say: "The W3C XML Schema Definition language is far from being targeted for elimination from Microsoft's actively developed portfolio." Obasanjo listed a dozen Microsoft products using XSD, including "Yukon," Visual Studio .Net, "Indigo," Word, Excel and InfoPath

The last three form the core of Office System 2003, which Bill Gates touted as the strategic development platform for the near future at the New York launch. With Longhorn still far away, Microsoft is asking developers to invest in XSD for now—only to have to unlearn and migrate when Longhorn appears in 2006.

As several people have pointed out WinFS schema and XSD do completely different things. A few people have suggested that Microsoft "embrace and extend" XSD to make it suitable to describe WinFS types but bitter experience has shown that this course of action usually leads to confusion amongst our customers and recrimination from industry watchers. In the words of Chris Rock, "You could drive a car with your feet if ya want to, that doesn't make it a good  idea!".

However Steve Gillmor's piece does point out the fact that the next couple of Microsoft releases targetted at developers will be bringing a number of new technologies for developers to learn and there will be pushback from those who don't see why they have to adjust to the changing landscape. Just today, I got an email from someone who pointed out that users of data access technologies in the .NET Framework will now have almost half a dozen distinct query languages to chose from when retrieving data including OPath, XPath, XQuery, and SQL. There are reasons why each one exists

  • OPath is an object query language
  • SQL is a relational query language
  • XPath is a dynamically typed language for addressing parts of an XML document
  • XQuery is a statically typed language for performing sophisticated queries on one or more XML documents.

However stating it bluntly there are twice as many query languages that will exist whenever the next version of SQL Server & Visual Studio ship than in the last version (OPath & XQuery are the new comers). I suspect that much the same way Steve Gillmor is writing "the sky is falling" style articles about the fact that there will be a schema language for describing WinFS types seperate from that for describing XML documents (yet as Mike Deem points out no seems to be asking why not use SQL 'CREATE TABLE' statements to define WinFS types) there will be similar complaints about the amount of choice we are giving developers with regards to data access technologies and query languages.

Sometimes I wonder whether developers would prefer an Über-language with everything and the kitchen sink integrated into it. Would developers really prefer that instead of having divergent query languages we just had one (i.e. SQL) with proprietary extensions for the different data domains which was used ubiqitously everywhere to query XML documents, in-memory objects, relational databases, text files, etc? If reporters like Jon Udell and Steve Gillmor are to be believed then this is the preferred approach to building software since on the surface people get to reuse their skills except that things will work differently than they expect. I'm actually curious to hear from developers who read my weblog as to which approach they think is preferrable. For example, should one use SQL to query relational databases and XPath/XQuery for XML or should SQL be the universal query language used by all with any additions needed for XML querying being grafted on to it in most likely a proprietary manner? 

This inquiring mind would like to know.


 

Tuesday, November 25, 2003 12:21:36 PM (GMT Standard Time, UTC+00:00)
While I can truefully state that I think all of the different query languages is a total pain, I have come to the conclusion that it is better to have them instead of a single SQL-like one. Why? Look at SQL today. It was designed to be exactly that - one query language for all RDBMS' out there. Today, however, there is one for each different RDBMS. Why? Because each vender wanted to make "their" SQL the best it could be - on their DB. SO I do not think that trying to have one language will work, even if you try.

David
David Williams
Tuesday, November 25, 2003 12:21:44 PM (GMT Standard Time, UTC+00:00)
While I can truefully state that I think all of the different query languages is a total pain, I have come to the conclusion that it is better to have them instead of a single SQL-like one. Why? Look at SQL today. It was designed to be exactly that - one query language for all RDBMS' out there. Today, however, there is one for each different RDBMS. Why? Because each vender wanted to make "their" SQL the best it could be - on their DB. SO I do not think that trying to have one language will work, even if you try.

David
David Williams
Tuesday, November 25, 2003 3:04:38 PM (GMT Standard Time, UTC+00:00)
I think you need different languages because the data being queried (many times) is fundamentally different. Take SQLXML for example, which gave people the ability to use XPath and XSD on a SQL data store. This caused a lot of confusion for XML developers who weren't familiar with how SQL Server stored data which is very different from an XML document.

So I like the different languages since you compromise too much when you try to have a one-size-fits-all language.
Tuesday, November 25, 2003 4:54:58 PM (GMT Standard Time, UTC+00:00)
The destination is Multi-Model Database Engines (Virtuoso and Oracle are pretty much there, and this is where Yukon is headed too). This emergent database engine architecture will simplify the alignment of task and database programming language (what is basically missing outside the products mentioned today).

WinFS/OPath, WebDAV/DASL, RDF/RDFQuery, RDBMS/SQL, XML-DB/ XQuery- XPath are examples of Query Language and Database format combos that will ultimately be supported by a wider variety of DB Engines.
Wednesday, November 26, 2003 3:48:31 AM (GMT Standard Time, UTC+00:00)
The complaint from developers that they have to learn some new thing seem more like sour grapes than logical argument. It is already obvious to me that XSD doesn't do everything we need it to. If it did, why is it that Relax NG and Schematron address issues that XSD can't?

What I'd like is for the naysayers to show proof that they can build a better mousetrap within the constraints they've put on Microsoft. If Mr. Gillmor is so wise in things technology, I'd like to see him define WinFS in term of XSD to be queried using only XPath 1.0. (Incidentally, since XQuery is XPath 2.0, I'm not sure it's really fair to say that they are two different languages.)

In short, I think the approach that Microsoft is taking with "Whidbey" and beyond is the best that I've seen.
Wednesday, November 26, 2003 8:31:36 AM (GMT Standard Time, UTC+00:00)
Having different languages is definitely better. By the way, is MS planning to add an XQuery compiler to Visual Studio? Considering that there is one for XAML, it world be weird not to have a compiler for XQuery.
George Mladenov
Comments are closed.