Re: ACTION-667: Created initial draft of GSP test suite 'script'

On 09/17/2012 06:14 PM, Chime Ogbuji wrote:
> I have added an initial draft of a sequence of HTTP message requests and responses as the basis for a GSP test suite.  This is according to the script agreed upon in the 8/7 teleconference [1]
>
> Sorry for not getting around to this sooner.
>
> See: http://www.w3.org/2009/sparql/docs/tests/data-sparql11/http-rdf-update/tests.txt
>
> [1] http://www.w3.org/2009/sparql/meeting/2012-08-07#Graph_Store_Protocol_testing
>

Looks good, Chime.    The basic concept seems fine, and the tests all 
look right to me.

A few minor questions/ideas/suggestions....

- Can we include a PUT/GET pair where the GET response includes the 
triples in a completely different format (maybe flat triples instead of 
using square brackets), to show that it doesn't have to be the same bytes?

- To my eye, $var$ is an odd substitution syntax.    I'm used to $var, 
$(var), ${var}, and {{var}}.   I think $var could have problems with 
some examples.    It's a tossup among the others, but I'd go with {{var}}.

- Shouldn't there be a $PREFIX or some such, so the first test would be:

    PUT $PREFIX$/person/1.ttl HTTP/1.1

I'm just thinking not every testable implementation is going to be at 
the root level on the machine it's on.

- Let's have a test without the .ttl suffix, lest someone think that's 
somehow necessary

- It would help to be more clear about where the test boundaries are.   
Some of these tests need to be run together in this sequence, 
essentially forming one test.  Others are independent.

- Brainstorming a little about whether this format should be somehow 
made machine readable.... using a microlanguage, or maybe RDF.    In 
RDF, I guess I'd do it like this:

     :test001
        rdfs:comment "PUT at an arbitrary URL, then GET of the same URL"
        :steps (

        [ # first request/respose pair
          :request
     """PUT /person/1.ttl HTTP/1.1
     Host: $HOST$
     Content-Type: text/turtle
     @prefix foaf: <http://xmlns.com/foaf/0.1/> .
     @prefix v: <http://www.w3.org/2006/vcard/ns#> .

     <http://$HOST$/person/1> a foaf:Person;
         foaf:businessCard [
             a v:VCard;
             v:fn "Jane Doe"
         ]""";
          :responseCode 201
        ]

        [ # second request/response pair
          :request
     """GET /person/1.ttl HTTP/1.1
     Host: $HOST$
     Accept: text/turtle; charset=utf-8
     """;
          :responseCode 200;
          :responseType "text/turtle";
          :responseRDFMatch
     """<http://$HOST$/person/1> a foaf:Person;
        foaf:businessCard [
             a v:VCard;
             v:fn "John Doe"
        ]""";
        ]
     ).

Okay, that was fun, but after doing that exercise, I'm now thinking (as 
I guess you are) that it's not worth it to make these tests directly 
machine runnable.   Implementing something that can understand and run 
these tests would be more work than implementing GSP, I think.

- It would, however, be nice to have a service that will run these tests 
for you.  You tell it your $PARAMETERS$ and it tests the service and 
reports back.   Any interest in running one of those... :-]         Or 
at least a publicly available python or bash script that does this (but 
it would need some tool that can do RDF graph comparison).

Okay, that's it for now!

         -- Sandro