- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 19 Oct 2004 19:41:28 -0500
- To: Karl Dubost <karl@w3.org>
- Cc: Norman Walsh <ndw@nwalsh.com>, public-webarch-comments@w3.org
On Oct 19, 2004, at 4:37 PM, Karl Dubost wrote: > > Le 15 oct. 2004, à 15:45, Norman Walsh a écrit : >> I don't find your use case compelling. It sounds like you're having >> trouble >> configuring your server to provide options for text/html or >> text/plain. > > You CAN NOT send an HTML file as text/plain using HTML features. Quite. That's by design, don't you think? > Example: I'm having a file foo.html which is served by the server as > an HTML file "text/html". > > In a doc.html, I want to show the source code of this file. > > <object data="http://example.org/foo.html" type="text/plain"> > <p>Source code of the Foo file.</p> > </object> > > > It will not be received by the browser as text/plain because by > specification definitions. HTTP overrules HTML. "Overrule" is an odd phrasing; the natural layering of the spec is that the containing protocol says how the contained data is to be interpreted, no? > The only way to change the representation of the file is to change the > name of the file, No, an HTTP server can offer other media types at the same address. Perhaps the popular ones don't support it out of the box, but it can be done. > to foo.html.txt for example, but you don't have anymore one file but > two files. > > HTML specs can not predate on the HTTP spec for this case and on the > server side, you don't know a priori if your file has to be sent in > text/plain or in text/html because you don't know it has been called > by an object element. > > I hope it explains a bit more the problem. Well, I see the situation that you're describing, but aside from implementation limitations, it seems by design and entirely consistent with Web architecture. > > I understand the meaning of the TAG on this section and I tend to > agree with > "A specification should clearly indicate which features advance into > territory rightfully governed by another specification." > > because it's dangerous. Though there are an evaluation of > cost/benefits in terms of technical values and usability. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 20 October 2004 00:41:30 UTC