- From: Graham Klyne <GK@ninebynine.org>
- Date: Tue, 13 Sep 2005 09:10:11 +0100
- To: Richard Newman <r.newman@reading.ac.uk>
- CC: andy.seaborne@hp.com, public-rdf-dawg-comments@w3.org
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