Application Cache review

This portion of the spec needs to be phrased better to improve  
clarity. I have several specific issues where the spec text is unclear  
or incomplete/inconsistent.

What is the difference between an application cache and an  
ApplicationCache object? There seems to be a difference as can be seen  
from the following spec text:
[[
A Document initially is not associated with an application cache, but  
can become associated with one ...

A cache host is a Document or a SharedWorkerGlobalScope object. A  
cache host can be associated with an application cache.

Each cache host has an associated ApplicationCache object.
]]

While a Document may not be associated with an application cache, it  
has an associated ApplicationCache object. This drove me nuts until I  
realized that the ApplicationCache object is not the same as an  
application cache.

Another problem I found is the following spec text that leads me to  
think that while an application cache has to have at least one  
resource, an ApplicationCache object can be empty, i.e., not have any  
resources:
[[
	An application cache is a set of cached resources consisting of:
		One or more resources ...

If there is no application cache group identified by manifest URL,  
then create a new application cache group identified by manifest URL.  
Initially, it has no application caches. One will be created later in  
this algorithm.
]]

What happens when I do
[[
	window.applicationCache
]]

but don't define any manifest attribute in the html of the window's  
document is that I get back an ApplicationCache object without  
entries. This conflicts with the above requirements even though the  
resulting behavior makes sense and the spec text doesn't.

Another area of trouble is the state of an application cache as  
opposed to that of an ApplicationCache object.
[[
Each application cache group has an update status, which is one of the  
following: idle, checking, downloading.

An application cache group can be marked as obsolete, meaning that it  
must be ignored when looking at what application cache groups exist.

   const unsigned short UNCACHED = 0;
   const unsigned short IDLE = 1;
   const unsigned short CHECKING = 2;
   const unsigned short DOWNLOADING = 3;
   const unsigned short UPDATEREADY = 4;
   const unsigned short OBSOLETE = 5;
   readonly attribute unsigned short status;
]]

There are two states here that are not referenced in the spec text -  
uncached and updateready. uncached is never mentioned in the text  
except in the IDL. updateready is mentioned as an event but appears  
nowhere as a status.

There are also some spurious passages, which appear as requirements  
but are not. For example,
[[
	A fallback namespace must not be listed more than once
]]

Turns out if a namespace is repeated, it is simply ignored.

[[
	If appropriate, remove any user interface indicating that an update  
for this cache is in progress.
]]

There is no mention the presence of a user interface to indicate cache  
update progress. Why this text is required is unclear.

I would also suggest that the app cache section use the term  
representation in place of resource (where appropriate) because the  
relevant RFC 2616 has very clear meanings associated with the term  
resource that does not apply to the spec text.

Before I suggest alternatives to improve the spec, I would like to  
understand if I am on the right track and what is the intention of  
this spec text.

Some other pieces need more spec text.

[[
If a resource is listed in the explicit section and matches an entry  
in the online whitelist, or if a resource matches both an entry in the  
fallback section and the online whitelist, the resource will taken  
from the cache, and the online whitelist entry will be ignored.
]]

What happens if a fallback namespace covers one of the explicit entries?

[[
All URLs in the manifest must have the same <scheme> as the manifest  
itself (either explicitly or implicitly, through the use of relative  
URLs).
]]

Is any scheme besides HTTP and HTTP(S) supported? Not explicitly said  
so.

[[
Atomically, so as to avoid race conditions, perform the following  
substeps:

If the status of the cache group is either checking or downloading,  
then abort this instance of the update process, as an update is  
already in progress for them.
]]

Atomically is not well defined here. What happens if the state of the  
cache group changes mid-stream of this algorithm?

[[
Attempts to fetch resources as part of the application cache update  
process may be done with cache-defeating semantics, to avoid problems  
with stale or inconsistent intermediary caches.
]]

What are these cache-defeating semantics? Where are they defined?

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