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.

Received on Monday, 12 September 2005 16:07:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC