Re: fixed https://foafssl.org/test/WebId

On 6 Jan 2012, at 12:04, Kingsley Idehen wrote:

> But, the semantics of fragment identifier don't really mandate comprehension on the part of user agents, solely.

The semantics of HTTP does.

> Thus, an HTTP server can do what the user agent failed to handle by processing a request for URL module fragment id. Now, to somewhat complicate matters, if the HTTP server is a Linked Data [Resource] Server (i.e, not an Information [Resource] Server) it can, by way of transparent content negotiation qos algorithm infer the user agent seeks the description of a name subject which it translates (via re-write rule) into:


There is no way for a client to know in advance that a server will be able to process a request-URI including a fragment identifier, and so Postel’s Law applies more than ever. It’s counterproductive to both the client and the server to send it without having this knowledge in advance.

There are three possible outcomes for such a request:

1. The server treats it differently, providing only the data related to that subject URI and nothing else
2. The server treats it identically as though there were requested without the fragment
3. The server responds with a 4xx (or other) status

In case (1), things are fine. In case (2), you have to parse the received data and extract only that relating to the subject URI. As you have no real way to distinguish a response according to (1) or (2), these would most likely be the same code-path. In case (3) — most likely to be the case on the balance of probabilities — you have to retry the request with the fragment stripped.

Thus, whatever happens you need to have code which strips the fragment, and you need to process responses which describe more than just the subject you’re interested in. Given that, there’s no clear benefit to the additional complexity required by not performing the simplest of simple string manipulation before making the request.

I’m not sure why there’s any confusion on this point. Even if the specs aren’t clear, the reality of the processing hoop-jumping should be enough dissuade anybody from thinking it might be a good idea.


> 1. sparql describe url
> 2. sparql construct url.
> 
> If it can't do the above, then, yes it can 404 or even 406.

or, indeed, 410. It _is_ a bad request, in every technical sense. '#' isn't a valid character to appear in the Request-URI.

> 
> Note: a Linked Data [Resource] Server is responsible for serving up Object/Entity descriptor resources to user agents. In a sense, they act on the missing DESCRIBE verb re. HTTP, which you get (deftly) via a sparql describe URL.

This distinction between a “Linked Data [Resource] Server” and an “Information [Resource] Server” is rather arbitrary, and runs counter to the principles of the WWW as far as I can see.

M.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Friday, 6 January 2012 12:35:42 UTC