- From: Adam Roben <aroben@apple.com>
- Date: Sat, 06 Oct 2007 14:31:32 -0700
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
Received on Saturday, 6 October 2007 14:31:32 UTC