Re: SPARQL Protocol Test Suite Update

Progress report:

I have some of the select/ tests working.

"working" is currently defined as issue the request and get back the correct 
HTTP response - I will increase the checking later.

Overall comments:

1/ I had to add a ptest:service triple to indicate which service to ask. As 
the tests are on different configurations of services (e.g. with a fixed 
dataset vs one described in the protocol), I need to ask different services 
for different tests.

2/ Data formats.

The name in the protocol request does not indicate the syntax of the data.  e.g.

       ptest:defaultGraph [
           ptest:graphName example:books;
           ptest:graphData 
<http://www.w3.org/2001/sw/DataAccess/proto-tests/data/select/svcsupplied-data.ttl>
            ] ;

The easiest way round this is to use only RDF/XML.

3/ Comments on manifest vocabulary as before.



Test comments::

== "select-svcsupplied" - passed

== "select-simple" - passed

== "select-complex" - passed

== "select-queryonly"

Wasn't sure what to do with <http://my.example/alice> and 
<http://my.example/bob>.  They aren't GETtable.

== "select-ambiguous"

No data for ambiguous-foaf-alice.n3 and ambiguous-foaf-bob.n3
CVS sync problems?

== "select-malformed" - passed

== "select-refused"

Not sure why the query is to be refused.

I'd return a 400 (BAD REQUEST) if query is sent that the (mythical) service 
description had said it was not supported in some way (e.g. described dataset 
but the service only has a fixed dataset).  It is not a server error if the 
client sends a request the server has said it can't handle.

[Insert discussion as to whether HTTP is an application protocol or not]

== "select-longpost"

The query is syntactically wrong (incomplete query pattern, the FROM clause 
needs a URI).

--------

So far : 4 of 8 of the select/ tests pass.

This is checked in Joseki3 CVS - the class "dev.RunTest" is the entry point.

 Andy



Seaborne, Andy wrote:
> Elias,
> 
> Any chance of using the same minfest vocabulary as for the query language 
> tests?  It means the same manifest parser can be used for the both - this is 
> what has just bitten me.
> 
> A manifest [1] is a list of tests - each test is an action and a result.  That 
> is slightly different to the ptest where the dataset, the query, the preferred 
> result and the acceptType are all properties off of the test itself.
> 
> If that manifest vocabulary doesn't work for you, I suggest we change the 
> manifest RDFS to create a reused piece of vocabulary.
> 
> Apologies - I should have followed through on this [2] and not left it so 
> late.  My fault.
> 
> It's not a road block - I could just copy the code and tweak it to work with 
> the ptest vocabulary.
> 
>  Andy
> 
> [1] http://www.w3.org/2001/sw/DataAccess/tests/test-manifest#
> [2] http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0248.html
> 
> Dan Connolly wrote:
> 
>>On Fri, 2005-10-14 at 11:02 -0400, Elias Torres wrote:
>>
>>
>>>
>>>
>>>Hi all,
>>>
>>>I wanted to update you on work I started to get a protocol test suite
>>>going,
>>
>>
>>Much appreciated.
>>
>>
>>
>>>any advice/direction is gladly welcomed.
>>
>>
>>Here's hoping I get time to study this closely soon.
>>
>>Everybody else, please join the fun!
>>
>>Gold star to the 1st person to reproduce Elias's results.
>>
> 
> 
>

Received on Monday, 24 October 2005 12:30:11 UTC