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

Richard Newman wrote:
> 
> 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.

Well, I use Haskell among other languages.  But you're right that it was 
about the Haskell implementation I was thinking.  I can see that other 
implementations can handle this case with ease.  Indeed, It is certainly 
possible to handle redefinition of prefixes in Haskell, and it's not a 
major effort.  But it does require that the code is more explicit about 
the order of processing, which means that more state has to be carried 
around the computation.  (I suppose that one of the features of 
functional programming is that it makes such matters more in-your-face.)

I thought some more about this issue last night, and while I still 
question this aspect of SOPARQL design (i.e. prefix redefinition) I 
think my original comment about implementation complexity is not the 
real one.  I think that this kind of multiple redefinition with a scope 
that is not really related to the language syntax (i.e. scope of 
definition from definition to redefinition, or to end of document) is 
not really a good language design.  My argument for this is more 
stylistic that technical, in the sense that I cannot say that there are 
specific cases for which it won't work well.

In the case of SPARQL in isolation alone, it may not matter much, but 
leveraging N3 syntax styles invites one to use SPARQL as part of a 
larger language using the same syntactic style (e.g. similar to the way 
I have used N3 elements in a broader scripting language in my SWISH 
project [1]).  In such contexts, where a language expression may involve 
multiple data and other expressions, I think that allowing redefinition 
of prefixes could allow some surprising errors to creep in, especially 
when multiple files are combined to create a single expression.

#g
--

[1] http://www.ninebynine.org/RDFNotes/Swish/Intro.html

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 13 September 2005 08:54:17 UTC