Re: 404 Re: Comments on the Triple Patterns Fragments draft

Hi David,

> I haven't completely understood that program code, so please correct me if I'm wrong, but it looks like line 94 checks the HTTP statusCode and emits an error if the statusCode is not 200, and (on lines 133-135?) an error is treated as an empty fragment page.

That is true.

This choice is application-specific:
this particular client evaluaties SPARQL queries over triple pattern fragments,
and incompleteness (= missing result) is preferred over an error.

> it looks like (on line 60) you are ignoring any statusCode that indicates an error, and treating anything other than 200 as merely indicating an empty result set -- effectively ignoring the fact that there was an error.

Yes.

> So if I have understood your code correctly, it seems to be either ignoring HTTP statusCodes that indicate errors (and treating them as merely indicating an empty result set), or it is not differentiating between a legitimate empty result set (which would come back as a 404) and a legitimate error condition

That's correct, because for this particular application,
it doesn't matter what the cause of the error is;
it simply means "could not retrieve matching triples".

An alternative would be to catch 5xx errors
and present them to the user,
but the envisaged user of this application
cannot do anything with these error messages.
So "error = missing" is here our error handling strategy.

> I do not see how that code avoids the added complexity that I mentioned, except by ignoring errors.

Note that (ignoring the HEAD request for now):
- The precise same error handling code would need to be there with or without the 404;
  because this application treats any error as "no matching triples".
- And, most importantly, if the server would return a 200 with an empty result set,
  everything still works: the fragment would get parsed (line 102)
  and the metadata (line 121) would indicate there are 0 matches.

So by giving a 404 error code for an empty result set,
we just bypass the parsing of the body (= added efficiency).
But if we don't bypass the parsing of the body (= no added complexity),
we will end up with the same conclusion: fragment is empty.

The HEAD request is the only place where the code assumes that
 "non-200 = empty" (line 59–60), "200 = non-empty" (line 61–62).
Therefore, if the triple pattern fragments spec is changed
to always return 200, the only code that needs to go is the HEAD request.

> I think we have to assume that many clients will want to treat errors as errors rather than ignoring them.

Exactly; as I mentioned, this SPARQL query client is an exception,
because those errors are meaningless to users of this client,
who talk SPARQL rather than HTTP.

> And if they do, then it seems to me that if 404 is treated merely as indicating an empty set of triples, then it would have to be special cased.

It depends on what the client wants to do, but yes, possibly.
Maybe I've been too focused on the SPARQL evaluation use case;
other use cases might not benefit from 404 for empty.

I have become convinced that it should be removed.

> Also, if 404 is merely treated as indicating an empty set of triples, then wouldn't it be indistinguishable from an actual 404 error condition where, for example, an incorrect base URI is used?

There would be no hypermedia controls in that error condition.

> BTW, the draft at
> http://www.hydra-cg.com/spec/latest/triple-pattern-fragments/
> is quite nice!   One suggestion: include a short use case example, showing URIs, requests and responses.

Thanks you!
That's a very welcome suggestion and I will definitely incorporate it in the next rewrite.

Best,

Ruben

Received on Friday, 1 August 2014 08:43:48 UTC