Re: ISSUE-81 (resource vs representation)

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 -
> 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  

>> A resource cannot be both a bag of bits and be an active object,  
>> e.g., make a
>> call or request another resource -
> 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.


Received on Tuesday, 6 October 2009 23:53:37 UTC