RE: ISSUE-81 (resource vs representation)

> 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