Here are some comments and questions about section 4.6 Offline Web
applications:
4.6.2
-----
The description of "Implicit entries" is unclear. My current
understanding is that the only kind of implicit entry you ever have is
a document that specified an application attribute on its html
element. The description of "The manifest" and the application cache
selection algorithm seem to support this. I think my confusion would
be cleared up if the first word in the description of "Implicit
resources" were "Documents" instead of "Resources".
Can javascript: URIs be used entries?
4.6.3.1
-------
"Manifests must specify all the URIs that are to be cached" seems to
be untrue: you don't have to specify the URI of any implicit
resources, or of the manifest itself.
It may be worth stating in this section what the behavior is when a
section or opportunistic caching namespace appears multiple times. The
parsing algorithm makes this clear, but it would be clearer still to
also state the behavior in this section.
4.6.3.2
-------
Section 4.6.3.1 says that the initial "CACHE MANIFEST" line may have
zero or more trailing space or tab characters, but step 9 of the
parsing algorithm says that trailing whitespace is disallowed.
Step 19: Beneath 'If mode is "fallback"', there are two places where
the phrase "opportunistic caching namespaces" is used. In both cases,
"namespaces" should be replaced with "namespace".
Step 19 should specify what the user agent's behavior should be when
an explicit or fallback URI is encountered which was already
encountered in an online whitelist section, or when an online
whitelist URI is encountered that was already encountered in an
explicit or fallback section.
Step 21 of the parsing algorithm should end with "and the online
whitelist URIs" instead of "and the online URIs".
4.6.4
-----
Steps 8.2 and 19.3.2 say that the user agent should "discard cache".
What does "discard cache" mean (in the case of an upgrade attempt,
"cache" is a possibly in-use cache)? In step 19.3.2, what is to be
done with "new cache"?
Step 19 should specify what should happen if a URI that is already in
the cache's online whitelist is to be added as an explicit, fallback,
or dynamic entry.
Step 22 should specify what should happen if a URI that is already in
the cache as an explicit, fallback, or dynamic entry is to be added to
the cache's online whitelist.
It would be good to make it clear in steps 19.{5,6,7,8} that an entry
can end up in multiple categories.
4.6.5.1
-------
What happens if the resource's URI is a javascript: URI? This seems
particularly interesting in the case of fallback URIs.
4.6.6
-----
Small typo in the description of the length attribute: "and zero the
object is not associated..." should have the word "if" between "zero"
and "the".
The description of the length attribute says "The length attribute
must return the number of entries in the application cache...", but
should I think say "The length attribute must return the number of
_dynamic_ entries in the application cache..." to be consistent with
subsequent paragraphs.
What happens if you add() a URI that is in the online whitelist?
Should an exception be thrown if remove() is called with a URI that is
not a dynamic entry?
In the definition of swapCache(), the Note in step 2 is unclear when
it says "this can only happen if...", as "this" could be interpreted
as either "success" or "abortion". I believe "success" is the correct
interpretation, but it would be nice to be clearer here.
-Adam
