Draft: open issues around '?' use.

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