RE: content negotiation anti-principle

Julian Reschke writes:
>Yes. I think in general only the client decice *what* it wants to
>bookmark, so it may be good to allow to bookmark both (the request-URI
>and the content-location-URI). Maybe we can get this into Mozilla
>quickly?

This may work well for bookmarking one kind of (common to Apache)
approach, but it's hardly a general answer to the question of how to
handle URIs (and especially URI references) in cases (all cases?) where
content negotiation is possible.

_If_ a fixed content-location-URI is available, then that's great, but
there are many cases - and XML+XSLT is making these cases easier to
create - where there is no content-location-URI.  The server returns a
representation which is a transformation based on an XML file (the "core
resource", perhaps?).   Only a subset of representations can be counted
on to have their own unique URIs.

Content-negotiation features are not part of the URI, but they determine
the representation returned quite directly and may not provide the
convenience of a content location header returned after the request is
made.

I'm not nearly as concerned with the "what do I bookmark after a
retrieval" question as I am with the "how do I as an author reliably
reference content" question.  Right now reliability is simply not
enabled unless you control both the point where the reference is made
and the thing to which reference is made.  Content-negotiation handling
could be far more robust in markup vocabularies including those created
by the W3C, but this has clearly NOT been a priority.

It doesn't seem like it should have to be that way, but the
(non-)intersections of [HTTP capabilities & URI philosophy] and [common
markup and browser practices] suggest that perhaps the world is more
comfortable overall with a single pathway from identifier to
representation.
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org

Received on Sunday, 5 January 2003 18:12:22 UTC