Thomas Broyer wrote:
On Tue, Nov 18, 2008 at 11:52 AM, Mike <[EMAIL PROTECTED]> wrote:
Thomas Broyer wrote:
On Mon, Nov 17, 2008 at 6:31 PM, <[EMAIL PROTECTED]> wrote:
- 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.
How would RSS work better than HTML (as of today; i.e. without your
proposed extension)?
RSS wouldn't work better - you asked for another way of doing this
without HTML, not a better way.
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.
That's one way of looking at things, not *the* way (see below).
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.
If you want to precisely identify the PDF "version" of that document,
you need another resource (whose representations is a set with a
single value: PDF).
If your URI idenfies "this document", you cannot blame anyone but
yourself for not being able to identify "this document in PDF".
If you want to precisely identify the PDF *representation* (version) of
that *resource* (document), you need the URI and your Accept headers set
correctly. To that end, the solution to this problem would be to put
example.com/document into a PDF reader. Or if you were writing an HTML
page, and you wanted to indicate in the <a> tag that the browser should
specifically request the PDF representation, you include an
Accept="application/pdf" attribute.
Does that not count as a use case for this proposal? Perhaps not, if you
believe that content negotiation belongs in the URI. This is a design
descision, and I believe that developers should be allowed to make this
descision at design time. Currently there is no standard in HTML to do
this; hence why I have proposed this optional Accept attribute. To give
the option and make it feasible to use HTTP content negotiation in web
applications.
I am yet to be provided with an example of where this addition could
cause any problems, so I don't understand the apparent resistance to
this; since it is clearly a valuable addition which enables HTTP conneg
in browsers.
Anyway, we're going real far from this WG's scope, so I propose we
follow up in private, or, even better, you re-hash the debate on the
rest-discuss list or with Roy T. Fielding if you want.
I completely agree that discussion is outside of the scope of this WG.
That is one of my main points here; It's a design decision that you are
taking out of the hands of developers by not provisioning the mechanism for.
I don't consider "well thats how its done and I don't think we need to
do it any other way" an acceptable response, since it *is* outside of
the scope of the WG and is a completely subjective standpoint. Not to
mention that your opinion suggests that HTTP conneg has no "practical
use", which I find hard to believe - feel free to explain why this is
the case rather than just explain that it isn't used at the moment, I
know it isn't!
Having to use a JavaScript virtual machine to perform PUT and DELETE is yet
another example of this.
Conforming to HTTP does not mean supporting all of the defined methods
(even at the server-side: a server is free to return a 501).
OK.. Why would you not want to do everything you could to support all of
the aspects of HTTP, particularly when you are being given a solution
that allows for backwards compatibility. I don't mind getting involved
and doing the work on this myself, if that means this will happen.
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.
So make another URI to identify that particular resource: "the same as
X but available only in format Y".
That's conneg in URIs. It should be reasonably apparent that I am aware
of this technique by now; I think the original post I made even said as
much!
I'm not saying that you cannot achieve conneg in URIs, I'm simply
pointing out that another approach is the make use of protocol level
conneg and avoid creating new URIs for every resource representation.
I'm not even claiming it's a superior approach; it's just a valid
alternative that makes proper use of the conneg provided in HTTP - HTML
could support this approach by implementing my proposal.
There is no choice at the moment because HTML is insufficient.
I believe HTML is not in cause here (as any format with hyperlinking
feature would be "insufficient" too: as I said above: PDF, MSOffice,
OpenDocument, RSS, Atom, etc.)
HTML is a hypermedia. Hypermedia are special case formats that should
allow UAs as much as possible to make best use of HTTP. One of the
examples you gave was Atom, which is going to great lengths making
amendments to support the HTTP protocol - for that very reason.
- 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?
No.
HTTP does not need HTML (WebDAV and CalDAV, for instance, do not need
HTML to work). and HTML does not need HTTP (aren't you sending HTML
mails yourself? and most documentation nowadays is in HTML format
stored on disk, without HTTP entering into play).
However, HTTP and HTML both make an heavy use of URI/URL.
HTML is the standard markup used for provisioning HTTP application GUIs.
If HTML only supports conneg in the URI.. guess what web application
developers do.. conneg in URIs! There is presently no alternative, so
there are very few web applications that use the alternative protocol
level conneg.
HTML is a markup, it doesn't make use of URIs - it indicates to clients
how to make use of URIs. Totally different thing.
- 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.
Let me try again: your document is available in HTML and PDF (let's
keep it simple). Who makes the HTML? Who makes the PDF? How can you be
100%-sure that both variants are strictly "identical" (if ever they
can)?
If they aren't identical; they aren't the same resource - and it would
be idiotic to serve them from the same URI.
Let's consider the famous "SVG tiger" image, that you would make
available in both SVG and PNG. Isn't the SVG qualitatively better than
the PNG? Aren't they the same resource "sketch of a tiger"?
'Better' ? I don't understand the point your making here..
What are your criteria for this judgment?
What if I think smaller file size is 'better'?
If the image represented in both formats is the same; they are the same
resource. My interpretation doesn't make you wrong, and yours doesn't
make me wrong. The only difference here is that my approach is currently
totally impractical because HTML provides no way of doing this
contextually within browsers.
How about an interactive animation you provide in both SVG+JS and
Flash. What if there's a bug the SVG variant (e.g. because of cross-UA
incompatibility)? They're the same resource, yet there can be
discrepencies between the two variants (and moreover in this case both
are directed to the same kind of UA: browsers, so you cannot even pick
up your favorite phrase "here's the animation, you can open it in XXX
or YYY")
Provided the animation is the same - the only discrepancy is the
representation of that animation (i.e. the content type).
Again, the case you have raised here is another important point; which
is that browsers handle alot of different content types and it depends
on the particular HTML page as to which representation you would want
the browser to display.
If you were insistent as a developer that only the flash representation
of the animation was only appropriate on a particular page; then you
*could* achieve this *if* your tag containing the reference to
example.com/animation had the attribute
Accept="application/x-shockwave-/flash/".
Or if you were happy that the browser could decide, you would leave the
tag off and let the browser send it's default Accept header - this is
probably the most likely case in this instance because both
representations render identically and are embedded so there's no real
incentive, in this particular case, to specify over the browser
defaults. Obviously if we are talking whether a link to
example.com/report returns a pdf or a word document - this is a
different use case.
I hope this has cleared up my position for you, if you still disagree
let me know - I dont think there's any reason to continue this in
private since this is all relevant information to the discussion - I
have no intention of debating with you over whether HTTP conneg is
superior to conneg in URIs or not, I just think both should be
provisioned for.
Regards,
Mike
