From the author... It didn't occur to me to make this point prior to deadline...
Think about SQL as something analogous to an application layer protocol such as POP3, which rides upon TCP, a transport layer protocol. (HTML over HTTP is another good analogy).
Usually what we see is that application layer protocols are developed after transport protocols, as was the case with POP3, IMAP, SIP, etc.
What's interesting about SQL is that it provides a reasonably platform neutral way of expressing queries, yet it does not have an Internet friendly transport protocol that it rides upon.
Imagine what the web would be like if it operated like today's database systems. We'd have a platform neutral markup language (HTML ... analogous to SQL), but each web server would have a different client/server transport protocol. I think you can see where this is heading, to lots of headaches, and that's basically where we are at today with respect to databases.
This really isn't such a radical proposal when you think of it in this context. The difficult job of building a reasonably vendor neutral query language was done a long time ago. All we need now is a simple HTTP oriented interface to complement proprietary client/server interfaces (e.g. ODBC).
The transport piece of the puzzle is actually much easier to deal with than the query language, as this is a simple two-step transaction: 1) XML-RPC method call going into the DB server with a consistent parameter list (one to the parameters being a SQL query), 2) XML recordset going out to the client. Piece of cake compared to implementing an email protocol like IMAP4.