- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Tue, 5 Aug 2008 15:19:48 +0100
- To: Karl Dubost <karl@w3.org>
- Cc: "T.V Raman" <raman@google.com>, seb@serialseb.com, www-tag@w3.org, kidehen@openlinksw.com, tthibodeau@openlinksw.com
On 1 Aug 2008, at 12:54, Karl Dubost wrote: > Let me create another example. > > 1. /resource > 2. /resource.html (sent as text/html) > 3. /resource.html (sent as text/plain) to view the source code > 4. /resource.txt (sent as text/plain) contain the text version (not > the source code) And you want that 2-4 are accessible by content negotiation from 1? I think this stretches things a bit. An HTML version of a resource, and the source code of said HTML, are quite different things and should be exposed to the world as separate resources. The tool of choice for getting from one to the other is hyperlinking, not content negotiation. The purpose of content negotiation is specifically to allow clients with different capabilities (that is, support for different formats) to transparently share a single identifier space. It is *not* about connecting different but related resources. (But let me add that it is a modelling question, and there are no “right” and “wrong” models, only more or less useful ones.) Richard > > > And I request with: Accept text/plain > > The case 3. is interesting when you want to show the html source > code a file without having to copy the html file twice and do > resource.html and resource.html.txt > > In the thread it has been suggested to send what was available, the > issue is which one resource.html (text/plain) or resource.txt. I'm > not sure there is an easy choice. For the json/html case it seems > easier to answer. > > > -- > Karl Dubost - W3C > http://www.w3.org/QA/ > Be Strict To Be Cool > > > > > >
Received on Tuesday, 5 August 2008 14:20:36 UTC