Re: 18. consequences.

Andy,

On 20 Apr 2011, at 12:35, Andy Seaborne wrote:
>> b) It is a change that breaks compatibility between SPARQL 1.0 and
>> SPARQL 1.1, in a *minor* and *easily characterized and motivated*
>> way.
> 
> I don't think it's minor.  Evidence to show it is would be good.

Well, there are web server logs from two major public SPARQL datasets available in the USEWOD dataset:
http://data.semanticweb.org/usewod/2011/challenge.html

This includes SPARQL queries ands could be used to get an idea of how common the “18.” case is. Not sure how representative that collection is etc

> or creates a syntax error in otherwise working systems (the case of "18. .").  

Implementations that are willing to go the extra mile for backwards compatibility *could* make this valid.

> That's a big deal for them and their software suppliers.
> 
> It's because of the success that these things become significant.
> 
> Establishing a message somehow that further changes to existing systems would be good.

Hmmm. To discourage that message, the SPARQL WG could in its public communication treat the change as a bugfix:

“SPARQL 1.0 had a bug in the grammar. A * in a production that was supposed to be +. This meant users couldn't end their triples with ‘18.’ as this would be treated as an xsd:decimal literal. This is fixed in SPARQL 1.1. If you *did* intentionally write xsd:decimals as ‘18.’ then you may have to update your queries and change it to ‘18.0’ .”

Obviously stretching the truth, but it doesn't send a message of arbitrary BC-breaking changes.

The alternative is to have Turtle deviate from SPARQL, or to “infect” yet another W3C rec with XSD's unfortunate design decision. In the *long run*, the user support costs of both options are higher than making the change now.

Personally I'm hugely looking forward to not having to worry about the whitespace rules around dot, semicolon and comma in Turtle and SPARQL any more. Imagine that: :Tommy a :Person. :Tommy :age 18.

(Also: The deviation of some implementations from the spec is far bigger than the spec change we are discussing here...)

Best,
Richard

Received on Wednesday, 20 April 2011 13:19:46 UTC