Re: Uniform access to descriptions

Xiaoshu Wang wrote:
>
> > I have read your references.  I disagree with your position in its
> > particulars, but in a larger sense I agree with the notion of using
> > content negotiation.  I have posted how I believe content
> > negotiation and 303 redirects may be used more properly for your
> > ends, than the method you have suggested.
> >   
> First, I do not think 303 solve my particular use case. 
> 

No, they don't.  Furthermore, conneg does not solve the problem of
attaching multiple RDF files to a resource, which is easy to do with
HTTP Link headers, as more than one is allowed.  I support httpRange-
14, I did not present my example as a solution to your problem but as a
response to what Pat said:

"In fact, if we were to agree on some simple protocols for content
negotiation which themselves referred to http codes, it could provide a
uniform mechanism for implementing the http-range decision."

> 
> Second, I still could not rational your example.  If you know the 
> relationship between [a-d], and you also understand what a client 
> request, I don't know why you have to use 303/400 but 200 to serve
> your client's request.  On the other hand, if you don't know the 
> /representation/describes relationship of [a-d], how can you serve it
> later?
>

It implements a "yes-no-maybe" check at the protocol layer.  The client
wants to know if an RDF document is available for a given URI, so the
client dereferences the URI with Accept: application/rdf+xml.

200 = yes
406 = no
303 = maybe

I think it's logical for a client to infer that the target of such a
303 redirect would have been served using a 200 response, if it were
indeed a representation of the request URI.  So the 303 means, maybe
there *is* an RDF document that relates to the request, but the client
won't be able to determine that without parsing the target of the 303.
The 303 response can include one or more Link headers, if more than one
RDF document applies to the originally-dereferenced URI.

>
> > Which does not change the fact that you're using a fringe case to
> > make your point, and said fringe case goes against proper Web
> > architecture, which sorta means referring to Web architecture
> > regardless of the delicate sensibilities of anyone on this list.
> >   
> Well, you call it a fringe case because you couldn't define it.
> Which one is a more proper architecture, the one with fewer fringe
> case or the one with more?  I think the theory of relativity is a
> *fringe* case w.r.t. classic physics.  And you can say the latter is
> the proper physics...what can I say?
> 

No strawmen, please.  I consider any HTTP implementation which
deliberately disables caching, in cases where caching is clearly still
desirable (as in your example), by going against a SHOULD in the spec,
etc. as a fringe case.  A conneg application which chooses not to send
Content-Location headers because caching is not desirable, is quite a
different thing from a conneg application which CANNOT send Content-
Location headers even when caching _would_ be desirable.  Again, my
solution to your use case is to refactor the application such that it
conforms with RFC 2616's intent, even if it does conform to the letter
of the spec as-is.

-Eric

Received on Monday, 14 April 2008 01:45:04 UTC