- From: Richard Newman <r.newman@reading.ac.uk>
- Date: Mon, 12 Sep 2005 09:07:05 -0700
- To: andy.seaborne@hp.com
- Cc: Graham Klyne <GK@ninebynine.org>, public-rdf-dawg-comments@w3.org
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 UTC