rewrite the static service tests to use a functioning location

[lisp]

the service tests are written in terms of non-existent service locations. for example service01.rq is

SELECT ?s ?o1 ?o2 
{
  ?s ?p1 ?o1 .
  SERVICE <http://example.org/sparql> {
    ?s ?p2 ?o2
  }
} 

for these static tests, replace the location with that of a functioning "service".
this should be either an actual sparql endpoint which contains the requisite dataset(s).
short of that, investigate either reducing the requirements such that a single response suffices for all tests or introducing result-specific locations for static responses.

[afs]

(The working group faced this challenge)

We, this community, can't provide that functioning service endpoint -- even if donated now, will it be operational next year or in 5 years, or longer time? And maintained at a 24x7 availability? From running sparql.org, I can say that providing adequate service without non-zero cost is depressingly difficult. Bad things happen all the time.

W3C were not in a position to offer that level of guarantee. Documenting that the endpoint needs replacing, is a poorer solution but one with better longer term durability.

[gkellogg]

(Chair hat off).

I think that for most purposes, using an additional file in the test suite repo which serves static results when accessed as a service endpoint will do much of what is requested. If the need is to validate that a processor properly composes an HTTP request to access the federated service endpoint, we'd need to rely on descriptions of expected HTTP headers which an implementor could use to separately verify requests are made properly.

Testing can't be perfect, but we can improve on existing tests using static techniques, IMO.

In the case above, consider service01.rq:

# SERVICE join with pattern in the default graph

PREFIX : <http://example.org/> 

SELECT ?s ?o1 ?o2 
{
  ?s ?p1 ?o1 .
  SERVICE <http://example.org/sparql> {
    ?s ?p2 ?o2
  }
} 

This might simply use the data01endpoint.ttl file as is describe in the manifest test entry:

# SERVICE join with pattern in the default graph

PREFIX : <http://example.org/> 

SELECT ?s ?o1 ?o2 
{
  ?s ?p1 ?o1 .
  SERVICE <data01endpoint.ttl-> {
    ?s ?p2 ?o2
  }
} 

Alternatively, it could remain as is, with the responsibility of the testing infrastructure to proxy a request for http://example.org/sparql to simply return <data01endpoint.ttl>, which has the same effect, but would only work properly in the case of a proxy mechanism to make the substitution.

[ericprud]

On Oct 16, 2015 11:30 PM, "Gregg Kellogg" notifications@github.com wrote:

(Chair hat off).

I think that for most purposes, using an additional file in the test
suite repo which serves static results when accessed as a service endpoint
will do much of what is requested. If the need is to validate that a
processor properly composes an HTTP request to access the federated service
endpoint, we'd need to rely on descriptions of expected HTTP headers which
an implementor could use to separately verify requests are made properly.

Testing can't be perfect, but we can improve on existing tests using
static techniques, IMO.

In the case above, consider service01.rq:

SERVICE join with pattern in the default graph

PREFIX : http://example.org/

SELECT ?s ?o1 ?o2
{
?s ?p1 ?o1 .
SERVICE http://example.org/sparql {
?s ?p2 ?o2
}
}

This might simply use the data01endpoint.ttl file as is describe in the
manifest test entry:

SERVICE join with pattern in the default graph

PREFIX : http://example.org/

SELECT ?s ?o1 ?o2
{
?s ?p1 ?o1 .
SERVICE <data01endpoint.ttl-> {
?s ?p2 ?o2
}
}

This tests the syntax and the job semantics but none of the mechanics of
constructing the subquery and sending it out over the wire (whatever wire
that might be). I'd say it depends on the objective of the test (which if
better understand were I not on my phone).

Alternatively, it could remain as is, with the responsibility of the
testing infrastructure to proxy a request for http://example.org/sparql to
simply return , which has the same effect, but would only work properly in
the case of a proxy mechanism to make the substitution.

—
Reply to this email directly or view it on GitHub.

[lisp]

at this point in sparql's life cycle, one goal should be to test interoperability.
which requires that endpoints be (made) known for conforming implementations.
in which case, if nothing else, the reflexive requests should locate a functioning service..

[afs]

endpoints be (made) known for conforming implementations.

The server target of SERVICE does not need to provide federated query itself for a test of (local query execution) SERVICE functionality.

We should not require "conforming implementation" to provide a public endpoint. It is not a separation of responsibilities of code writing and code operation. It would imply an implementation team can actually put up and sustain a public endpoint.

[lisp]

yes, the client and server side if that relation are distinct, yet if sparql as a standard expects to claim that federation serves any purpose, it will have to demonstrate that it works. the current tests do not accomplish this.

a short look at the state of the protocol test does not convince, that that would make a better home.

[gkellogg]

If people would like to have a conference call to discuss such issues, I'm sure we can get time on the W3C WebEx account and use our #rdf-tests IRC channel for a meeting. Let me know, and I'll send out a Doodle for those interested.

[gkellogg]

I have an email out to @ericprud and @philarcher1 to help coordinate this, but it will probably need to wait until after TPAC.