Re: ISSUE-81 (resource vs representation)

On Sep 27, 2009, at 3:23 AM, Maciej Stachowiak wrote:

>
> On Sep 27, 2009, at 2:45 AM, Julian Reschke wrote:
>
>> Maciej Stachowiak wrote:
>>> ...
>>> More generally, I don't think it makes sense to require HTML5 to  
>>> use words with multiple meanings as technical terms in the exact  
>>> same way as dependency specifications. There are too many  
>>> dependencies, and they use words in different ways. I would only  
>>> be concerned if there is actual confusion (as opposed to the  
>>> purely hypothetical confusion in this case).
>>> ...
>>
>> Not sure what counts as "dependency" specification. I'm ready to  
>> believe that HTML5 currently references other specs that get this  
>> wrong, too. But what's relevant here are the specs that define the  
>> term.
>
> To give a specific example, Unicode, ECMAScript and CSS all define  
> the term "property" in completely different ways. And HTML5 adds yet  
> another distinct definition in a different context. As far as I'm  
> concerned, this is not a problem, because it's always clear what is  
> meant.
>
> Another example: RFC3986 has a different (much more general)  
> definition of "resource" than the HTTP RFC.
>
>> Furthermore, as explained earlier, HTML5 is inconsistent in itself;  
>> and that's something that should be fixed. If "Foobar" is the thing  
>> identified by a URL (HTML5) then it simply can't be a bag-of-bits  
>> at the same time.
>
> Natural language is context-sensitive. I don't think any actual  
> confusion is caused.


I could present counterexamples to your assertion. 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 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
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"?
A resource may not be external - e.g., a javascript: URL? What bits  
does an "internal" resource imply?
A resource may be a sub resource. However, what exactly is one - does  
it have a URI without a fragment identifier? Can I tell based on  
looking only at the URI whether something is a subresource? If not,  
which parts of an HTML user agent be affected by the semantics of  
subresources?
Each entry in the list of pending master entries of an application  
cache consists of a resource and a Document object. What is the  
relation between the resource, the master resource, and the resource's  
Document?
Multiple application caches can contain the same resource. Does this  
mean they each have their own bags of bits or just the URL of that  
resource? When selecting an application cache, what is it that user  
agents look for a bag of bits or the URI of the resource being searched?
When I think of cookies, they are per host and path, and not per  
resource. What then is the meaning of a resource's cookies as  
suggested in 3.1.3?

Can "resource" be all of the following at the same time?
A resource may have metadata (per section 2.5.1)
A resource may generate Request-URIs (per section 2.1.1)
A resource may be external or not (per section 2.1.1)
A resource has semantics (per section 2.1.1)
A resource has a format or type (per section 2.1.1)
A resource may have metadata (per section 2.5.1)
A resource has an identifier (per section 2.5.1)
A resource can be fetched (per section 2.6)
A resource may be incrementally processed (per section 2.6)
A resource may or may not be available (per section 2.6)
A resource may be cached (per section 2.6)
A resource may be type sniffed (per section 2.6)
A resource has a host (per section 2.6.2)
A resource can be either binary or text (per section 2.6.3)
A resource has cookies (per section 3.1.3)
Something may be a subresource (per section 4.2.4)

Perhaps a certain amount of context switching will be required of the  
reader, no matter what. Perhaps we expect every user agent developer  
and Web author to understand this complexity. Regardless, this  
document will certainly be adding to the entropy around resources.

I would like to hear your responses rather than spend a lot of my time  
digging through the spec to find more instances of confusion caused by  
the undefined terms "resource", "subresource", "external resource" and  
their interchangeable use with other terms.

Nikunj
http://o-micron.blogspot.com