- From: Dirk-Willem van Gulik <dirkx@webweaving.org>
- Date: Mon, 25 Oct 2004 02:35:37 -0700 (PDT)
- To: public-rdf-dawg@w3.org
Within the draft the '?' is used to denote a variable and '$' is mentioned as a possible synonim/placeholder. In a significant number of environments we expect the SPARQL query language to be used along side SQL query language. They even may appear in the same soure files. Given their different nature we do not expect SPARQL to ever replace SQL; but see a joint future. So it is essential that these two co-exist. In SQL the '?' is used as a placeholder indicator in quite a few popular languages/database interface methods. And thus does not have the meaning of a variable. To some extend this may make the learning curve steeper and slow adoption. A second issue is that in a number of language environments a precompiler or IDE extension mechanism is used to trap the '?' and ':' placeholders by essentially scanning for any (dynamic/embedded) SQL like strings with a ?. INTEGER deptno = 123 ... SELECT name, no FROM personell WHERE department = ?deptno This is common when SQL is used along with (older) C/C++, PLI and COBOL. In those environments one is forced to keep code containing SQL and SPARQL in separate files and/or specific build chains. We believe that this slows adoption considerably during the adaption perod. Though we acknowledge the argument that some of these tools are 'broken' when they search and replace too liberal; we should also be cognant to the fact that a lot of this is old code; unlikely to have priority with the vendors. A third issue is that we found existing ODBC and JDBC interfaces for SQL databases are near ideal to also deal with SPARQL without change on the client side - except for the fact that each will trap the ? early and reconstruct the SQL string before passing it on to the *DBC. (i.e. the prepare() versus execute()). $sth = $dbh->prepare('SELECT * FROM people WHERE lastname = ?') $sth->execute('foo'); # and over the *DB iface goes: # SELECT * FROM people WHERE lastname = 'foo' We believe that allowing developers to access to SPARQL through their well known ODBC and JDBC interfaces speeds up adoption considerably. This allows for a wide range of things; at the low end direct integration into Microsoft Excel or similar right off the bat - and at the high end leveraging of fail over interfaces and caches. Given the already messy situation around vendor specific escaping and the use of stored procedures or other functions to define escpae characters on the fly we do not believe that escaping at SQL solves this issue. Especially as this is more an adoption/curve steepness issue that a hard tecnical one; everything (but for the *DBC leverage) has work arounds. With respect to the '?' issue; we therefore propose the following -> Investigate if it is possible to change/tighten the syntax to allow the engine to distinguish between a VAR and QNAME without needing the ? prefix. -> Replace the '?' by a '$' or '_' or at the very least allow the use of a '$' or '_' as a synomym for the '?'. Should the '$' or '_' not be acceptable; the = and # may be alternatives. Though the $ may confuse in, say perl, we've not found *DBC and other API's in combinations with languages where the $ is used as variable prefix where it caused problems. As in this case escaping DOES help; as it is a language level escape. e.g. the typical pattern is: $foo = 'bar'; $sparql1 = ' ... $foo, ..'; $sparql2 = "...\$foo ...'; (note that my vim syntax colouring does get it wrong :-) and unlike SQL escaping each language is consistent in its own escaping options by nessecity. As to other choises we'd rather avoid the likes of *+-^|& due to their use in mathematics; but have only found one example of a precompiler (DB2) which actually looks at them (the || and &&). We'd strongly would like to avoid the . and : as these also have special placeholder/abbreviate semantics trapped by a few precompilers and *DBC interfaces. Thanks, Dw.
Received on Monday, 25 October 2004 09:36:37 UTC