RE: On Parameters

Hello Steve and Andy,

> * How are the processors supposed to determine the type of the
> arguments? eg is x=1 the integer "1"^^xsd:integer, the xsd:string/
> plain literal "1", or the local URI <1>, and so on. ...&x=%221%22%5E%5E
> %3Chttp%3A//www.w3.org/2001/XMLSchema%23integer%3E seems somewhat
> clumsy.

We use SPARQL syntax, so &x=1 and &x="1" and &x=<1> differ.

> As a general note, I personally don't find the "SQL does it, so should
> we" viewpoint to be very persuasive. SPARQL is not SQL, and many
> things in SQL are questionable. I think we should be looking to learn
> from their mistakes, as well as the things they did well.

Concorde is similar to Tu-144 and Buran is similar to Space Shuttle that is in turn similar to Bor not due to "commies does it, so should
 we". Same purpose and same atmosphere, nothing but. Still, it may be reasonable to look around, what else is flying in the same atmosphere :)

> If we do spec this feature, I'd like to see both mandatory and optional parameters.  Optional parameters can done using the existing named variables - the advantage of optional is that when results from one query are being used to drive another, optionals do occur.  The added checking of mandatory parameters, with variables with a distinguished name (?:name was suggested) is, I feel, sufficiently valuable to justify the additional specing.
> This is not a backward compatible feature.  How much do we want to smooth the transition for SPARQL/2010 [*] clients querying SPARQL/2008 servers?

We're intending to introduce tons of features that will cause troubles
for SPARQL/2008. Parameters is at least something that will cause
unambiguous errors.

BTW. re. parameters ?format, ?query and the like: we start parameter
names with ':' in both query text and the request, so &query=... and
&:query=... are easily distinguishable.

Best Regards,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

Received on Wednesday, 25 March 2009 17:24:11 UTC