On 30/03/12 16:52, Claude Warren wrote:
I have a case where I am using multiple federated calls where each call is
of the form
Service silent<uri> {
--snip--
}
One of the endpoints is returning bad data in that the XML does not parse
and so the XML parser throws an exception and my entire query dies.
Now the best answer would be to get the data corected but I don't own that
data and have no idea if they will fix it.
What I want to know is shouldn't the "Silent" keyword on the Service call
indicate that if the remote fails it should be ignored.
From http://www.w3.org/2009/sparql/docs/fed/service#serviceFailure it
appears that a single solution with no bindings should be returned. If
this is a correct interpretation I am willing to report a bug and implement
a bug fix. The issue that I see is that the error is not detected until a
hasNext() is called on the iterator. This means that the service could
have returned some data before the error was detected. I would propose
that the solution be to have the iterator return "false" at that point and
move forward with the partial data that was already returned.
Does anyone have a different interpretation of the specification or see an
issue with the possible solution?
Many thanks,
Claude
Hi Claude,
Hmm - tricky :-)
The key sentence is:
[[
The SILENT keyword indicates that errors encountered while accessing a
remote SPARQL endpoint should be ignored while processing the query.
]]
but HTTP has a bit of an issue here.
Suppose the request is made and "200 OK" is received. That's a contract
that the results are going to be sent and be valid. Bad syntax of
results isn't considered nor are breaks in communications.
The only way the address is for the service operations (class
QueryIterService) to consume and buffer all the results. I've just
added this in QueryIterService.
An effect of this is that you will not get any valid earlier results;
which is what you propose and quite sensible.
There needs to be a QueryIterator implementation that reads another
QueryIterator until some error occurs and signal end at that point.
That would be worthwhile - please do contribute such a thing.
Theer's a QueryIteratorWrapper that can be used to intercept
.hasNext/.next calls so you can add try-ctach.
Do you which SPARQL implementation is generating bad results?
Andy
