W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > September 2005

Re: Comments on last-call SPARQL draft 20050721, section 2

From: Richard Newman <r.newman@reading.ac.uk>
Date: Mon, 12 Sep 2005 09:07:05 -0700
Message-Id: <FE70BC90-40F2-4C9B-B8CE-3317CE7E3F95@reading.ac.uk>
Cc: Graham Klyne <GK@ninebynine.org>, public-rdf-dawg-comments@w3.org
To: andy.seaborne@hp.com


On 12 Sep 2005, at 04:15, Seaborne, Andy wrote:
>> Section 2.1, "Query term syntax", para 4
>> I feel that allowing a prefix to be redefined as described could  
>> create some small unnecessary complication for implementations  
>> that don't process the query sequentially, and creates scope for  
>> implementation errors.  I would suggest not allowing prefixes to  
>> be redefined.  Is there a compelling case for allowing such  
>> redefinition?
>
> Could you say more?  I'm having trouble understanding a SPARQL  
> implementation that does not process the SPARQL grammar which is  
> itself sequential.  Iguess the parser could be leaving qnames  
> unexpanded in parsing for later resolution but that second pass  
> over the query can be with the correct prefixes.  Because prefixes  
> come before any qnames, it isn't the case there can be
>  PREFIX ... qname ... PREFIX  Prefixes must take an quoted IRI  
> reference.
>
> (I believe the rational to allow redefinind prefxies was based on  
> the observation that other systems do it and we saw no reason to be  
> different (e.g. N3, XML namespace declarations)).

I imagine, (and this is suggested by GK being a Haskell programmer,  
IIRC?), that some implementations in parallel or lazy languages might  
have difficulty with redefinition.

OTOH, in twinql I do prefix expansion during the parse of the query,  
not during its execution, so I found no difficulties -- the parsing  
is naturally sequential, and prefixes are stored in a hash table, so  
redefinitions are straightforward. The last expansion for any prefix  
ends up in the hash, and is used for resolution of qnames.

-R
Received on Monday, 12 September 2005 16:07:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:49 GMT