Thomas Broyer wrote:
On Mon, Nov 17, 2008 at 6:31 PM, <[EMAIL PROTECTED]> wrote:
Would the sender of that link necessarily know all the formats the URL
provides? Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message
and send it without any surrounding text.
Whereas without any other information, people will generally open URLs
in a web browser. So it'd be faster just to send the URL of the page
which contains hypertext links to all the formats; at which point we no
longer care whether those links specify the format in the URL or
elsewhere.
- The HTML version of that URL could provide the web page representation
*and* provide links to all the other content types available.
How about other representations? (I know we're discussing HTML here,
and not HTTP, but what if a resource has no HTML representation? are
you proposing adding this capability to PDF, MSOffice, OpenDocument,
et al. too?)
That's an issue at the application level; RSS would work fine in that
situation - any form of hypermedia will serve that purpose.
What is the point of doing it in HTTP if it's being done in HTML anyway?
- Nothing is 'done' in HTML, it's a markup language. It's being done (at the
moment) in the URI. HTTP provides conneg, why would you consciously
deny developers the opportunity to use it in browsers? Unless HTML5
provides the markup, this isn't possible. This means Browsers don't have
the ability to fully support HTTP without having to use JavaScript rubbish;
there is a window of opportunity to change this with HTML5.
No. Browsers fully support HTTP in the sense that they send an Accept
header dependent of their *capabilities*.
If you want client-driven conneg, then use agent-driven/transparent
(RFCs 2295/2296), not server-driven conneg. This is explicitly noted
in RFC 2616 that server-driven negotiation has limits and can be
disadvantageous depending on your needs.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12
My argument is to provision both and let developers decide.
True. But if the current way of doing it is good enough, there's no
incentive to change."
- Define 'enough'..! I don't know why/how you get the authority to
make that assumption! And before you say it; I'm not assuming any
authority myself - I'm trying to encourage you to help browsers conform
to the protocol they make use of.
Maybe you could explain how browsers do not conform to HTTP? (and no,
HTTP does not mandate user-agents to give the control of the Accept-*
headers to the user or the... server?!)
URI = Uniform Resource Identifier
A given document available in html, pdf, xml - is one resource. The
various content types are representations of that resource.
Because HTML is presently insufficient in providing a mechanism for
browsers to perform protocol level conneg.. it's been moved into the URI
and each representation is provided as a separate resource. This clearly
breaks the intended definition of a URI - this is why I don't consider
browsers to conform to HTTP; since they force developers to misuse that
part of the protocol.
Having to use a JavaScript virtual machine to perform PUT and DELETE is
yet another example of this.
There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the
servers the ability to describe the available variants of a given
resource in a content-type independent way. You'd rather push browser
vendors to implement TCN/RSVA than HTML5 to add a content-type
dependent equivalent.
See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5
I don't really understand the point your making.. I would just like to
see a way by which developers can link to *resources* with URIs and
specify the representation if and when necessary for a given link. There
is no choice at the moment because HTML is insufficient. An optional
Accept attribute would address this issue and still allow for the
current methods that you feel (subjectively) are 'sufficient'.
- I'll say it again: I'm encouraging you to help browsers become
better HTTP clients; surely that is high on the agenda here.. right?!
No, we're discussing HTML and some "Web APIs" here, not HTTP.
So the Transfer Protocol (HTTP) and the Markup Language (HTML) for Hyper
Text are not closely linked?
If you aren't discussing it that way; it might be worth considering, no?
Or what about if I wanted to mail somebody pointing out a discrepency
between two versions of the report, and wished to link to both of them.
That's tricky if they have the same URL. Possibly I could do it like
you have with the wget command-line above, but that requires me knowing
which browsers my audience use and the precise syntax for them."
- separate versions are separate resources, not separate content types. That
has nothing to do with conneg..
s/version/variant/
Variants still need be produced by someone or something, and there
really might be discrepencies between them; that's why there's a
"quality" parameter in TCN/RSVA (and thus in Apache type-map files,
for instance)
I'm not sure what you're getting at here. Multiple versions are multiple
resources, they aren't seperate types so conneg is not appropriate. URIs
handle this, the example I gave (which you left out) is proof of that.
Regards,
Mike
