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

Re: GSP validator and tests

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 19 Oct 2012 16:49:44 +0100
Message-ID: <50817698.6030106@epimorphics.com>
To: public-rdf-dawg@w3.org

On 17/10/12 06:14, Chime Ogbuji wrote:
> There is now a validator for GSP implementations listening here:
> http://metacognition.info/gsp_validation/gsp.validator.form

Progress report:


Did I miss a way to get an EARL report? c.f. the protocol validator.

== The validator only tried 18 of 22 tests

Fuseki did not receive any multipart tests (which it does not implement) 
(test 15 and the check 16)

I may never implement these because it conflicts with treating the graph 
store itself RESTfully - i.e. POST of data means append to the store 
(quads or triples)

== Rerunning the tests I got:

gsp.validator.run =>
Internal Server Error

Server got itself in trouble
Error 500

so then I lost the report at that point :-(

== Test 5 - "PUT - default graph"

A PUT to /ds/?default
expected status 201, received 204 ()

?? The default graph always exists so it should never return 201 (created)

== Turtle content type:

The content type for Turtle is

Content-type: text/turtle; charset=utf-8

== Coverage

Are there no tests for graph= ?

PUTing via direct and GETting indirect, and vice versa, would good tests 
to have.

== Empty graphs

Whether a graph store response 200 or 404 to an empty graph is best left 
untested or at least documented in the tests - the same issues arise in 
SPARQL Update.

A quad store might respond 404 to an empty graph or even always say 200 
to any graph.

The only other option is to acknowledge that GSP forces choice of 
implementation technology.

== Practical assumptions

This test was running with an experimental service that was processing 
any protocol and any request.  This is less secure (normal security 
frameworks can't spot updates so easily - e.g. Apache Shiro).

I had to add /ds as the graph store as well.  Fuseki does not support 
graph store on "/" because it conflicts with serving up HTML pages. 
Standard servlet dispatch by name gets confused and having to analysis 
each request in the application is unnecessary work and make si thard to 
integrate with other protocols (SPARQL protocol, plain old pages).

== What is the graph store?
(discussion point)

I was initially confused by GRAPHSTORE:

$GRAPHSTORE$ is the path of the URL of the graph store

but operations include:

PUT /person/1.ttl

so doesn't that mean GRAPHSTORE is fixed as "/person" or as "/" because 
graphs named directly are within the naming tree of the graph store?

This is all a bit of problem because it is presuming how services are named
Graph Store - A mutable repository of RDF graphs managed by one or more 
so the "graph store" does not a URI? only the services?

For Fuseki, the graph store and the services normally have different 
URLs (it helps with security amongst other things).

For the tests, I was running with a all-purpose processor on the graph 
store URL

Received on Friday, 19 October 2012 15:50:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:08 UTC