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

On Wed, Nov 25, 2009 at 6:08 PM, Michael Nelson <mln@cs.odu.edu> wrote:
>> 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.

I don't draw much of a distinction there, at least for the purposes of
discussions like this; they are all URLs in an HTTP response message.

>>
>> 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.

I didn't mean to imply it wasn't done.  As Richard (and Larry, in his
referenced message) point out, User-Agent conneg is pretty common.  I
was just trying to point out that it's not used nearly as often as
client selection.

> 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.

I used to use w3.org as an example too, but I've learned since that
it's the exception, not the rule, for Web site design.

>>> 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.

Fair enough.  I'm just offering you my advice based on my extensive
experience in this space.  You're free not to believe me, of course
8-)

As long as you're also supporting agent driven conneg, I'm happy.

>> - 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

Ah, I see.  Yes, I agree that's a good design choice.

>> 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.

Content negotiation is a valuable tool, so I'm glad there's interest,
but IMO, both of those documents misrepresent it by only describing
the server-driven form.

Mark.

Received on Thursday, 26 November 2009 20:49:14 UTC