- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Tue, 6 Oct 2009 16:50:43 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Maciej Stachowiak <mjs@apple.com>, HTMLWG WG <public-html@w3.org>
On Oct 5, 2009, at 10:25 PM, Ian Hickson wrote: > On Mon, 28 Sep 2009, Nikunj R. Mehta wrote: >> >> Here are a few examples of the confusion caused by fungible use of >> the >> terms resource, file, and object/document. >> >> A file cannot have infinite length - a resource can - >> http://dev.w3.org/html5/spec/Overview.html#concept-fetch-total > > A file can have infinite length; consider /dev/urandom, for instance. Granted. However, what is the logic to use file in the following spec text inside the section "fetching resources"? Are you saying the two are interchangeable: [[ If the user agent can determine the actual length of the file being fetched for an instance of this algorithm, and if that length is finite, then that length is the file's size. Otherwise, the subject of the algorithm (that is, the file being fetched) has no known size. (For example, the HTTP Content-Length header might provide this information.) ]] > > >> A resource cannot be both a bag of bits and be an active object, >> e.g., make a >> call or request another resource - >> http://dev.w3.org/html5/spec/Overview.html#fetching-resources > > Could you quote the exact text you think is problematic here? I provided this in several prior emails and repeating again for your benefit. This is from step 2 of "fetching resources" [[ address of the resource from which Request-URIs are obtained ]] > > >> A resource is a bag of bits, but fetching a resource brings back a >> set of >> "out-of-band" headers as well. How does this make sense? Where does >> the "bag" >> start or end? What exactly is "out-of-band"? > > It makes sense in the same way that a file in a filesystem has out > of band > information, forked streams, ACLs, a filename, etc. A file is /distinct/ from the stream you obtain when you _fopen_ it. The stream doesn't have metadata, but the file does. Since you are interchangeably using file and stream, i.e., resource and representation, such confusion is bound to occur in your spec text. I suggest you revisit this point and provide a clear explanation for why this is better and consistent with reality. > >> I have done more than enough to prove this point. I think my issue >> requires a sincere response. The alternative is to wait for another >> editor to come around some years from now and start yet another blame >> game about how messed up the terminology is and so how it needs to be >> totally redone regardless of what came before it. > > 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. > As you have acknowledged, you are redefining the term resource to mean a bag of bits without any concrete evidence of confusion caused by formal terminology for this concept i.e., "representation". The net result is that your vocabulary is causing confusion and I have demonstrated where that is the case. I continue to believe that your approach is detrimental to the understanding of HTML5. Nikunj http://o-micron.blogspot.com
Received on Tuesday, 6 October 2009 23:53:37 UTC