Mark Baker wonders if XQuery shouldn't be able to work using GET. Mark is responding, at least in part to a post by Dave Orchard about XQuery and the Web. Dave says at one point:

The ability to compare URIs is crucial for caching., hence why so much work went into specifying how they are absolutized and canonically compared. But clearly XQuery inputs are not going to be sent in URIs, so how do we have cachable XQueries gven that the query will be in a soap header?

From Dave Orchard's Blog: Xquery: Meet the Web
Referenced Fri Jan 09 2004 13:11:52 GMT-0700

If you look at some sample Xqueries you'll see why Dave says what he does. XQuery is not the kind of thing you can imagine being encoded in a URI in a way that humans can write it and know what it means. Its just too verbose. You'd have to serialize it and, to my mind, that defeats the purpose.

So that leaves us with two real choices:

1. Clearly XPath queries can be put in URLs.
2. We can continue to encapsulate verbose, general-purpose queries like we've been doing for almost a decade on the Web and then reference them in URIs.

I wonder if general purpose queries are the right things to be in URLs anyway. If all a GET does is give me access to the SQL engine through the Web, then the designer of the system hasn't really done much for me. Most Web facing data sources have some purpose in mind and encapsulated queries are one of the ways that the system designer adds value to the data source. If that were not true, we could all just get along with an SQL shell for everything.