W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

sparql extensions and protocol conformance

From: Gregory Williams <greg@evilfunhouse.com>
Date: Mon, 26 Apr 2010 11:36:31 -0400
Message-Id: <4A84A6A3-FCC1-4512-85D6-8602015754F2@evilfunhouse.com>
To: SPARQL Working Group WG <public-rdf-dawg@w3.org>
A ran across what I think is an issue in a discussion with DanC on #swig the other day. Right now the protocol spec says in section 2.1.1.3.1 (MalformedQuery):

> When the value of the query type is not a legal sequence of characters in the language defined by the SPARQL grammar, the MalformedQuery or QueryRequestRefused fault message must be returned.

I'm concerned about this because the service description document specifically provides for endpoints to describe what extensions to sparql they implement (with sd:languageExtension). My hope was for this to aid in implementations converging on extensions beyond what 1.1 provides, just as we're now standardizing several things that were implemented as extensions on top of 1.0 (update, aggregates, project expressions, basic federation, etc.). Yet the wording of the protocol document suggests that you couldn't implement any syntactic extension to SPARQL 1.1 and still be a conformant SPARQL endpoint.

I'm not sure if the wording in the protocol document is meant to use "MUST" in the RFC 2119 sense, but I think the intention is clear. I wonder if anyone would entertain the idea of changing that to SHOULD, which I think could allow the language extension case I discuss above.

On IRC Lee said,

> I don't know how to allow the protocol to accomodate syntax extensions (is XQuery a syntax extension to SPARQL? how about versa? what about "fj328jf2832#@"?) without making protocol conformance pretty meaningless

My initial thought on this would be to think of valid endpoints as those that produced the correct answer to all valid SPARQL queries, but also might produce answers to non-valid SPARQL queries. This would allow implementors to play around with extensions and hopefully lead towards useful functionality that could be input to a next round of standardization.

Does anyone have thoughts on this issue? If we continue to say that an endpoint must return an error if the query string isn't valid w.r.t. the grammar, does that affect the endpoint's ability to validly claim sd:supportedLanguage sd:SPARQL11Query? Or is it still a conformant SPARQL *Query* implementation, just not a conformant *Protocol* implementation?

thanks,
.greg
Received on Monday, 26 April 2010 15:37:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:42 GMT