- From: Larry Masinter <masinter@adobe.com>
- Date: Tue, 6 Oct 2009 16:20:04 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: HTMLWG WG <public-html@w3.org>
> If there are specific things you think the spec says that are > contradictory (like the parsing manifests section did), then please do > raise those points. However, I don't see anything wrong with using the > term "resource" in a manner consistent with how it is used throughout the > industry. I continue to think that HTTP, URI, and the handful of related > specs that insist on considering the term "resource" as excluding files > are the exception here, not the rule. For a specification that goes out of its way, in other ways, to be careful to "match reality", this is a case where being following sloppy industry terminology leads to a failure to be consistent with the reality of what is actually implemented. There are two different concepts: XXXX: the thing that a Uniform Resource Identifier identifies, that a Uniform Resource Locator locates. YYYY: the bits + metadata you get, when you "fetch" an XXXX. In reality, these things are different, and using the same word for them adds a great deal of confusion. There are XXXX's that only have one YYYY -- when the XXXX is a file, but there are XXXX's that have NO YYYY at all -- for example, a telnet: or irc: URI, and there are XXXX's that have multiple YYYY's, e.g., when there is content negotiation. If you use the same word for both, it gets very confusing about whether the URI resource is the same resource as the fetched resource. If you want to match reality and describe these in a specification about the web, it seems you need two words. For better or worse, the word "resource" was used for XXXX, because, you know, a Uniform Resource Identifier, well, maybe you should use "resource" for that thing. And so we were stuck looking for another word for YYYY, and, well, "representation" seemed to fit, so the specs talk about "representations" of "resources". This distinction was made in some places, but of course, the popular confounding of the two is still widespread. I suppose you could say "result-of-fetching-resource" or some other term than "representation"? I don't think, as a general editorial policy, that precision and "matching implementation reality" should have higher priority than correspondence with popular usage; I would think most would agree with this. I also think that consistency with other highly relevant technical specifications (including those referenced by this document) should also have editorial priority over over popular usage; perhaps there is more disagreement over this? So I urge a review of the use of the term "resource" in the document to determine, for each case, whether the term "representation" (as used more formally) would more accurately reflect reality. Regards, Larry -- http://larry.masinter.net
Received on Tuesday, 6 October 2009 23:20:44 UTC