- From: Mike <mike@mykanjo.co.uk>
- Date: Wed, 19 Nov 2008 13:22:37 +0000
Thomas Broyer wrote: > On Tue, Nov 18, 2008 at 11:52 AM, Mike <mike at mykanjo.co.uk> wrote: > >> Thomas Broyer wrote: >> >>> On Mon, Nov 17, 2008 at 6:31 PM, <mike at mykanjo.co.uk> 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
Received on Wednesday, 19 November 2008 05:22:37 UTC