- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 22 Aug 2006 10:38:30 +0200
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mon, Aug 21, 2006 at 05:35:20PM +0100, Seaborne, Andy wrote:
>
> To do these tests, we need negative syntax tests:
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0246
>
> For reference: Eric's alternative (which I think is unnecessary because it
> changes existing test manifests):
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0052.html
The fact that action is sometimes a bnode with a query property and
sometimes a query directly seems counterintuitive and forces one to
write more awkward queries to get at the data (forces the common case
queries and data to be OPTIONAL) . Do you specifically want it that
way, or are you worried about updating the tests?
mf:action
[ qt:query <expr-1.rq> ;
qt:data <data-1.ttl> ] ;
vs.
mf:action <syn-02.rq> ;
> Andy
>
> -------- Original Message --------
> Subject: Re: Determining whether '<' is a beginning of IRI or 'less than'
> operator [OK?]
> Date: Fri, 18 Aug 2006 20:27:37 +0100
> From: Dan Connolly <connolly@w3.org>
> Organization: W3C (http://www.w3.org/)
> To: Seaborne, Andy <andy.seaborne@hp.com>
> CC: Jiri Dokulil <dokulil@gmail.com>, <public-rdf-dawg-comments@w3.org>
> References: <6a8224ab0608180833r31f8c81flb4d0c3037286aab3@mail.gmail.com>
> <44E60817.10308@hp.com>
>
> On Fri, 2006-08-18 at 19:33 +0100, Seaborne, Andy wrote:
> >
> >
> >Jiri Dokulil wrote:
> >>
> >> I am not sure how should scanner for SPARQL determine whether '<'
> >> character it encountered is beginning of an IRI or a comparison
> >> operator.
> >>
> >> Consider these queries:
> >>
> >> SELECT * WHERE { ?a ?b ?c, ?d . FILTER(?a<?b && ?c>?d) }
> >> SELECT * WHERE { ?a ?b ?c, ?d . FILTER(?a<?b&&?c>?d) }
> >>
> >> Yacker validator results look troubling to me:
> >>
> >http://www.w3.org/2005/01/yacker/uploads/SPARQL?markup=html〈=perl&text=SELECT+*+WHERE+%7B+%3Fa+%3Fb+%3Fc%2C+%3Fd+.+FILTER%28%3Fa%3C%3Fb+%26%26+%3Fc%3E%3Fd%29+%7D&action=validate+text
> >> >
> >http://www.w3.org/2005/01/yacker/uploads/SPARQL?markup=html〈=perl&text=SELECT+*+WHERE+%7B+%3Fa+%3Fb+%3Fc%2C+%3Fd+.+FILTER%28%3Fa%3C%3Fb%26%26%3Fc%3E%3Fd%29+%7D%0D%0A&action=validate+text
> >> >
> >> The first query validates, the other does not.
>
> I believe that's by design, as Andy explained below.
>
> Andy, let's get this case in the test suite and ask
> the WG to confirm. Is that convenient for you to do?
>
> Thanks, Jiri, for the careful review.
>
> >The rule "longest token wins" resolves the tokenizing problem (and is
> >common practice in lexers because it also means 123 is a single number,
> >not 3 individual one digit numbers) although it moves the problem to the
> >grammar.
> >
> >It could be disambiguated but it needs more than changes to the lexer. It
> >needs a context sensitive lexer (< and an IRI can't occur in the same
> >place in a valid expression, after ?a seeing < must be a comparison in a
> >legal expression). The WG has chosen to cover the wider range of parser
> >toolkits, rather than chose the more complicated context sensitive
> >approach.
> >
> >I'll look at adding an editorial note that highlights this better. It does
> >already say:
> >
> >http://www.w3.org/TR/rdf-sparql-query/#whitespace
> >"""
> >White space (production WS) is used to separate two terminals which would
> >otherwise be (mis-)recognized as one terminal.
> >"""
> >which already covers this case.
> >
> >I hope that this message addresses you comment. If it does, please let us
> >know - if you put [CLOSED] in the subject line, it will help scripts that
> >help manage this list.
> >
> > Andy
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
>
>
--
-eric
home-office: +1.617.395.1213 (usually 900-2300 CET)
+33.1.45.35.62.14
cell: +33.6.73.84.87.26
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Tuesday, 22 August 2006 08:37:14 UTC