Re: RDF Update Feeds + URI time travel on HTTP-level

Mark,

>> In practice, agent-driven CN is rarely done (I can only guess as to why). In
>> practice, you get either server-driven (as defined in RFC 2616) or
>> transparent CN (introduced in RFC 2616 (well, RFC 2068 actually), but really
>> defined in RFCs 2295 & 2296).  See:
>> http://httpd.apache.org/docs/2.3/content-negotiation.html
>
> I disagree.  I would say that agent-driven negotiation is by far the
> most common form of conneg in use today.  Only it's not done through
> standardized means such as the Alternates header, but instead via
> language and format specific links embedded in HTML, e.g. "Click here
> for the PDF version", or a "Language/country-selector dropdown" in the
> page header, or even via Javascript based selection.

While the exact line between them might be hard to draw, I'd argue those 
aren't HTTP-level events, but instead are HTML-level events.  In other 
words, I would call those examples "navigation".  In addition, navigation 
works well for things that can be expressed in HTML wrappers (e.g., "click 
here for the PDF version"), but not really for embed/img tags where you 
want to choose between, say, .png & .gif.

>
> Server driven conneg, in comparison, is effectively unused.  Ditto for
> transparent negotiation.

I think that is an unfair characterization.  I won't guess as to how often 
it is done, but it is done.  It is just not perceived by the user.

Almost every browser sends out various "Accept" request headers, and it is 
not uncommon to have "Vary" and "TCN: Choice" response headers (check 
responses from w3c.org, for example).  When done with the 200 response + 
"Content-Location" header, the URI that the browser displays does not 
change.

Also, if you link directly to "uncool" URIs (e.g., "foo.gif" or 
"bar.html"), you won't see any traces of CN in the response because those 
URIs aren't subject to negotiation.

>> So while I think you are describing agent-driven CN (or something very
>> similar), I also think it would be desirable to go ahead and get the full
>> monty and define the appropriate Accept header and allow server-driven &
>> transparent CN.  Agent-driven CN is still available for clients that wish to
>> do so.
>
> I just don't understand the desire for server driven conneg when agent
> driven is the clear winner and has so many advantages;

we'll have to agree to disagree on that; I think they are different 
modalities.

>
> - not needing to use the inconsistently-implemented Vary header, so
> there's no risk of cache pollution. see
> http://www.mnot.net/blog/2007/06/20/proxy_caching#comment-2989
> - more visible to search engines
> - simpler for developers, as it's just links returned by the server
> like the rest of their app. no need for new server side modules either
>

I would suggest these are among the reasons we champion the 302 response + 
"Location" header approach (as opposed to "200/Content-Location") -- it 
makes the negotation more transparent

> You might also be interested to read this, where one of the RFC 2616
> editors apologizes for supporting server driven conneg;
>
> http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html
>
> Note that he refers to HTTP conneg being broken, but is actually only
> talking about server driven conneg.

I would counter with that fact that CN features prominently in:

http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
http://www.w3.org/TR/cooluris/

Given the role CN plays in these recent documents, it would seem CN has 
some measure of acceptance in the LOD community.

regards,

Michael

>
> I think that makes for a pretty strong case against it, and I haven't
> even elaborated on the architectural problems I perceive with it
> (though some of the advantages above relate closely).
>
> Mark.
>

----
Michael L. Nelson mln@cs.odu.edu http://www.cs.odu.edu/~mln/
Dept of Computer Science, Old Dominion University, Norfolk VA 23529
+1 757 683 6393 +1 757 683 4900 (f)