W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: SPARQL Protocol Test Suite Update

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 25 Oct 2005 10:47:18 +0100
Message-ID: <435DFF26.7070706@hp.com>
To: Elias Torres <eliast@us.ibm.com>
CC: public-rdf-dawg@w3.org



Elias Torres wrote:
> 
> 
> 
> 
> Andy,
> 
> So are we going to merge the manifests? I think you worked around it for
> now, but I think it'd better if we solved this early on so we don't have
> almost identical schemas.
> 
> Regards,
> 
> Elias Torres
> Software Engineer
> IBM
> 

I'm happy to change if/whenever suits you.  Have code that parses the ptest 
formats (mostly, it's just the other code with renamed properties) but I'd 
liek to use the same code everywhere as the other manifest code understands 
"includes".

Just let me know when you change it - I'm working off of a copy anyway as I 
need to add ptest:service properties to get the tests working at the moment.

	Andy



> "Seaborne, Andy" <andy.seaborne@hp.com> wrote on 10/24/2005 08:29:00 AM:
> 
> 
>>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.
> 
> 
> I updated from CVS and did not find this new predicate. Do you mean
> something like:
> 
> ptest:service <http://sparl.org/books> ?
> 
> 
>>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.
> 
> 
> Should we add a predicate to the test? Is this a protocol matter whether
> both servers/clients do auto content-type discovery or content-negotiation?
> 
> 
>>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.
> 
> 
> This is what I pointed out in my first email to the list. That's why the
> dataSet has a graphName and graphLocation so I could do a search and
> replace on the query before executing the test. However, I'm not sure if
> this defeats the purpose of the test or not. Probably not.
> 
> 
>>== "select-ambiguous"
>>
>>No data for ambiguous-foaf-alice.n3 and ambiguous-foaf-bob.n3
>>CVS sync problems?
> 
> 
> No CVS sync problems. I have not finished this test yet.
> 
> 
>>== "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.
> 
> 
> That's excellent progress. You should be getting a gold star from DanC very
> soon. BTW, they are not all expected to pass yet.
> 
> 
>>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 towork
> 
> 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 Tuesday, 25 October 2005 09:48:43 GMT

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