W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: ISSUE-18: How do we parse "18." in Turtle?

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 30 Mar 2011 20:51:57 +0100
Message-ID: <4D9389DD.9060901@epimorphics.com>
To: Sandro Hawke <sandro@w3.org>
CC: nathan@webr3.org, RDF Working Group WG <public-rdf-wg@w3.org>

On 30/03/11 18:46, Sandro Hawke wrote:
> Andy said this is out of scope for SPARQL to fix, but I'm wondering if
> it isn't just an erratum, and thus in scope.   How many folks write
> SPARQL decimal numbers without trailing digits, relying on this
> behavior, before the "}"?

Hard to tell (without breaking the gramamr and seeing who yells).

As an erratum, it is a change to SPARQL 1.0 so I don't think it's so 
simple to wave "erratum" at it.

Personally, I'd be happy with the change but I'd like to understand the 
implications on users.

By the way, this is not the only place that "longest token" is important:

{ :x :p18. }

is that ":p1 8."  or ":p 18" or ":p18" and an error?  That has not been 
a practical issue raised.

Or  ?x<a&&b>?y

or ns:123 (legal SPARQL BTW because of comments on a WD.  Some domains 
e.g. lifesciences, naturally have all numeric local parts to URIs.)

The ns:123 is an issue for Turtle.

Issue suggested on the tracker.

I think Eric has taken the SPARQL defn in the working document so it 
going from illegal to legal.

Peter wrote:
 >> However, the problem is that when using the standard cheat

I think "cheat" is a bit judgemental :-) It is very common and based on 
finite state automata to drive the tokenizer. Lexer speed is very 
important and this is well understood and well know how to make fast.

In a prog lang:

intxyz=18 ;

and no one worries that there is a required space for "int xyz"

Received on Wednesday, 30 March 2011 19:52:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC