Re: ISSUE-81 (resource vs representation)

On Sep 28, 2009, at 4:35 PM, Maciej Stachowiak wrote:

> On Sep 28, 2009, at 3:27 PM, Nikunj R. Mehta wrote:
>> On Sep 27, 2009, at 3:23 AM, Maciej Stachowiak wrote:
>>> On Sep 27, 2009, at 2:45 AM, Julian Reschke wrote:
>>>> 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.
> Before I go searching in the spec, may I ask if you were sincerely  
> unable to find the answers to the following questions in normative  
> spec text?

Short answer - NO.

There is no normative text defining a resource, subresource, or  
external resource, or a resource's Document. There is also no  
normative text around the substitution of file, document, and object  
for resource.

I have to guess what is the Document for a resource (i.e., bag of  
bits). However, I don't know what is the value of the document's  
address given just the resource. What will I get when I create a  
Document given a URL with a fragment identifier?

I can devise answers for some of the questions below, but none are  
based on the normative text in the spec. It is simply based on my  
understanding of HTML and HTTP.

Take another look at the following two sentences and you will see why  
I am complaining.

When the user agent is required (by other parts of this specification)  
to start the application cache update process for an absolute URL  
purported to identify a manifest, or for an application cache group,  
potentially given a particular cache host, and potentially given a new  
master resource

If these steps were invoked with a new master resource, then add the  
resource, along with the resource's Document, to cache group's list of  
pending master entries.

Can you tell what is meant by the master resource in this statement?  
Is it a URL or a bag of bits or both? What is the meaning of a  
resource's Document? Is it the DOM obtained by parsing the resource  
per HTML's rules?

Another one from the same section:
One or more resources (including their out-of-band metadata, such as  
HTTP headers, if any), identified by URLs, each falling into one (or  
more) of the following categories:

Master entries - Documents that were added to the cache because a  
browsing context was navigated to that document and the document  
indicated that this was its cache, using the manifest attribute.

Let explicit URLs be an initially empty list of explicit entries.


Is an entry a URL or a bag of bits or both? When did I have to context  

>> A file cannot have infinite length - a resource can -
>> A resource cannot be both a bag of bits and be an active object,  
>> e.g., make a call or request another resource -
>> 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?
> As far as I can tell, yes. Can you clarify which of the following  
> properties you think are mutually exclusive?

I have listed above that which I think are mutually exclusive. If you  
think I am not making sense, can you please point out where and why?

>> 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.
> I'll do my best to reply further if you can provide the answers to  
> my two questions above.

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.

> Regards,
> Maciej


Received on Tuesday, 29 September 2009 00:21:35 UTC