Comment on SPARQL query language spec (nit)

I'm working on a SPARQL implementation, based on:
   http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050217/
and offer some comments:

...

This document seems to trigger a minor bug in Firefox.
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 
Firefox/1.0.1)

If I examine this online, it's fine, but if I save the web page to a local 
file and view it then some of the section headings get strange characters 
in them.  I guess it may be mis-handling of – in Firefox.

I've added this URI to an existing firefox bug report -- please don't 
change the document at this URI (as if you would!).

...

The table-of-content name for section 10 differs from the in-body heading 
("Query forms" vs "Result forms").

...

Trying to implement SPARQL, I'm finding that I have problems 
cross-referencing between the syntax (appendix A) and the corresponding 
descriptive text in the body of the document.  For example, there is a 
syntax production for "prolog", but it's not clear where this is explained 
in the text.  In particular, I can't find any reference to the BASE 
declaration other than in the formal syntax.

Suggest:  (a) syntax productions are repeated in the document body 
alongside the corresponding descriptions, or (b) syntax productions contain 
cross-references to the sections containing their descriptions.

...

The grammar in appendix A is very difficult to search in a browser, due to 
strange use of styles to render the text as upper case; e.g. consider the 
production for "PrefixDecl, which has an RHS that displays thus:
   'PREFIX' <QNAME_NS> QuotedURI
but whose HTML source is thus:
[[
<span class="token">'prefix'</span> <a 
href="#rQNAME_NS">&lt;QNAME_NS&gt;</a> <a href="#rQuotedURI">QuotedURI</a>
]]
using *lower case* for the 'prefix' text.  This means that a case-sensitive 
search for PREFIX does not work.

...

It is odd that some grammar terms named with angle brackets, while others 
are simple names?  The distinction here between lexical tokens and other 
tokens is really an implementation issue, and has no place in a 
specification whose purpose is to describe just what constitutes a 
syntactically valid SPARQL query.  I may choose to use a different set of 
lexemes and still be conformant in any observable sense.

...

I was initially confused that the given syntax for GraphPattern appears to 
prohibit a URI in the object position; cf. productions [22] [27].  It's 
only when I get to production[50] that the matter is resolved.  I think 
production [50] should be named URIorLiteral.

...

I note the punctuation decision referenced:
   http://www.w3.org/2001/sw/DataAccess/ftf4.html#item18
and offer an opinion that I would prefer the N3/Turtle approach, partly on 
the basis that I already have code to deal with these structures.  Even if 
it's not "official" there's a lot of N3 (and the like) "out there", and 
introducing yet another syntax seems to be unhelpful.

...

I don't find the syntax productions [53] [60] to be very helpful.  Perl 5 
regular expressions include a whole range of features that aren't obviously 
useful for SPARQL, and represents big chunk of additional "hidden" 
specification material to be analyzed in detail (I'm looking at over 70 
pages of a Perl reference book dealing just with regexes, and that doesn't 
include a grammar for them).

I would find it much easier if the relevant syntax and matching rules were 
included in the SPARQL spec.  At least, provide a specific reference to the 
pattern specification intended.

I think interoperability would be better served if a basic simple regexp 
syntax was defined (a subset of what Perl 5 allows), with implicit scope 
for individual implementations to offer more.  Otherwise, I feel the burden 
of getting the whole regex thing right will mean this feature is not always 
implemented properly.  (I have a particular problem with this because the 
Haskell regex library depends on posix support that isn't available on 
vanilla Windows platforms.)

Production[60] doesn't appear to be used.

...

That's all for now.  I expect there'll be more.

#g


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

Received on Wednesday, 6 April 2005 18:26:36 UTC