Re: ISSUE-81 (resource vs representation)

On Tue, 6 Oct 2009, Nikunj R. Mehta wrote:
> 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 information.)
> ]]

Yeah, the two are used interchangeably there. To reduce confusion, I've 
changed "file" to "resource" in that paragraph.

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

That's a term from the HTTP spec. I agree that it's a misuse of the 
terminology, but since HTTP is an RFC, there's no good way to do a 
cross-reference into the spec, so I can't really do anything but just 
quote the term to which this spec is to refer verbatim.

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

No, "stream" is the term used for the I/O primitive used to read the file, 
but the data itself is from the file, and it is the file that you open 
when you read it.

> Since you are interchangeably using file and stream, i.e., resource and 
> representation, such confusion is bound to occur in your spec text.

Confusion abounds in the HTML5 spec merely because it is a huge document 
written over many years. As the spec matures and people report the areas 
that confuse them, the confusion gets fixed. This has nothing to do with 
the weird use of the word "resource" that HTTP uses.

> I suggest you revisit this point and provide a clear explanation for why 
> this is better and consistent with reality.

Because people refer to HTML and JPEG files as "resources" and pretending 
that "resource" means some sort of ephemeral abstract concept between a 
URL and a file (I nearly said resource!) is simply not consistent with the 
way this terminology is used by the majority of Web authors. (Similarly, 
people don't refer to the data in a file as separate from the file 

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

I continue to disagree.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 12 October 2009 06:14:35 UTC