W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

RE: Limited complexity requirement?

From: Rob Shearer <Rob.Shearer@networkinference.com>
Date: Thu, 15 Jul 2004 08:28:16 -0700
Message-ID: <CFE388CECDDB1E43AB1F60136BEB49730280FE@rome.ad.networkinference.com>
To: "Dan Connolly" <connolly@w3.org>, <public-rdf-dawg@w3.org>

I tend to agree with the general philosophy (a tiny turing-incomplete
subset of XQuery would be great, with the point being that support for
full XQuery is a sensible extension in those environments where it is
useful), but frankly the fact that you can't express the halting problem
doesn't solve any of the implement/deploy/secure/optimize issues. My
frequent refrain is "people don't generally publicize full SQL
interfaces", and there are good reasons that they don't. It is quite
easy to string together enough joins in SQL to form a practically
insoluble query; DOS attacks and the like are possible in even very tiny

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org 
> [mailto:public-rdf-dawg-request@w3.org] On Behalf Of Dan Connolly
> Sent: Thursday, July 15, 2004 7:54 AM
> To: public-rdf-dawg@w3.org
> Subject: Limited complexity requirement?
> While thinking about xquery-based designs, I realized I have been 
> assuming the following requirement. What do other folks think?
> 3.X Limited complexity
> Less expressive languages are easier to implement, deploy, 
> secure, and 
> optimize (cf the Principle of Least Poser in an essay on design 
> principles for the Web[1]). Since a large and interesting class of 
> applications can be addressed with query languages that are less 
> expressive than programming languages, this design should not 
> involve a 
> turning-complete query evaluator. The halting problem must not be 
> expressible in this query language design.
> [1] http://www.w3.org/DesignIssues/Principles
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> mobile: tel:+1-816-616-6576
Received on Thursday, 15 July 2004 11:33:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC