LCWD comments

Dear WebApps WG,

In this message I state my LC comments on the following documents:
[a] http://www.w3.org/TR/2009/WD-eventsource-20091222/
[b] http://www.w3.org/TR/2009/WD-webstorage-20091222/
[c] http://www.w3.org/TR/2009/WD-workers-20091222/

Some comments on particular drafts apply to those listed later above as well.

0. In [a]:
> The W3C Web Apps Working Group
It's either "WebApps" or "Web Applications" according to the charter.

1. [a] references HTML5 which is unlikely to go to Rec any time soon. What path do you envision following to resolve this? In particular, do you agree that these bits are generic, not specific to HTML, and therefore should be in separate specs and become Recs sooner (possibly at first with only a subset of what's currently in the HTML5 draft, given the possibility of multiple reiterations)? (Reminder: charters of our groups call explicitly for aligning such issues.)

2. In [a]:
> HTTP 302 Found, 303 See Other, and 307 Temporary Redirect responses must cause the user agent to connect to the new server-specified URL, but if the user agent needs to again request the resource at a later point, it must return to the previously specified URL for this event source.
Does it include only requesting a representation of the resource using the same EventSource object, the same browsing context, or globally (as long as the UA remembers having requested it before)? Is this consistent (especially for 303) with HTTP semantics?

3. In [a]:
> Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection.
I'm unsure whether it doesn't violate semantics of some HTTP codes already defined. But it surely imposes limits on what future codes may indicate, flying in the face of this extensibility point. All that this spec should say about the potentially coming unknown is that semantics of other codes must be applied as required for them.

4. text/event-stream uses text before / which is inappropriate and should be application. Entities of type text must be, at least as the last resort, feasible for rendering to the user as text (which not any sequence of octets is, e.g. text/html, but application/msword).

5. In [a]:
> formats of event framing defined by other applicable specifications may be supported
What is event framing? Additionally, are we going to have „other applicable specifications” extension point everywhere? For the moment it's just a beast dwelling in the HTML5 spec, tolerated until it gets its extensibility story straight, but if it's going to affect other specs in this way, the TAG should certainly have a look.

6. Section 10 of [a] seems something new in W3C's LCs. What is the story behind specifying requirements on finalization (note that this name is better, since "garbage collection" looks like limiting this behaviour to environments with a GC) and some rules stating when a spec should include them? Has there been any architectural discussion about it?

7. In [b]:
> The term "JavaScript" is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known.
The term "JavaScript" already refers to a proprietary implementation of ECMAScript. A confusion should not be entrenched further just because it's common. Clarity will be appreciated by intended readers of the spec, of whom knowledge of this distinction can be safely assumed. The term is unused anyway.

8. In [b]:
> To mitigate this, pages can use SSL.
Please change to TLS which is the standard name.

9. [b] states more precise requirements on scripts running in the context of an HTMLDocument than otherwise. Should some of them apply more widely?

10. In [c]:
> the MIME type of the script is ignored
This is a new spec. It shouldn't be plagued with such idiosyncratic legacy mechanisms.

11. In [c]:
> there is no way to override the type. It's always assumed to be JavaScript.
This is a violation of orthogonality for no real benefit.

12. In [c]:
> If there are any outstanding transactions that have callbacks
What's a transaction, when has it got a callback?

13. Why does [c] define ErrorEvent instead of reusing DOMError? Besides, it uses a misnamed attribute "filename" and suboptimally spelled "lineno".

14. In [c]:
> Thus, scripts must be external files with the same scheme as the original page: you can't load a script from a data: URL
Why impose this restriction? Is it that exceptions to same-origin policy when it's still new would be confusing for specifiers and the audience, so this possibility is postponed to the next version? In any case, I suggest allowing workers to be instantiated with Function objects (whatever this may be in language bindings, given positive resolution of 11) as well. Including workers directly inline seems natural in many scenarios.

15. Why using URI fragments is not allowed when instantiating workers? If it remains so, the spec should say that used URIs MUST be absolute (keeping unchanged the behaviour in the other case as error recovery).

16. In [c]:
> The DOM APIs (Node objects, Document  objects, etc) are not available to workers in this version of this specification.
I understand this as not being forbidden if an implementation provides such an extension. However, those APIs would operate on nodes floating in the air, unrelated to any document possibly opened.

17. Isn't there already something like WorkerLocation specced?

Best regards,

Krzysztof Maczyński
Invited Expert, HTML WG

Received on Thursday, 1 July 2010 02:09:49 UTC