Re: On Parameters

On 25 Mar 2009, at 17:14, Ivan Mikhailov wrote:

> 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.

That sounds OK, but I don't think there's consensus on that because I  
think I've seen bare terms in other examples.

>> 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 :)

My point was that some things standardised by SQL are, with the  
benefit of hindsight, mistakes. Lets be sure that we don't blindly  
copy them.

>> 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.

My organisation is keen to avoid introducing anything that will cause  
trouble.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Wednesday, 25 March 2009 22:02:41 UTC