12510 2011-04-16 02:11:08 +0000 Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous 2012-10-29 21:50:49 +0000 1 1 1 Unclassified WebAppsWG WebSocket API (editor: Ian Hickson) unspecified All All NEW xref P2 normal --- 1 glenn glenn art.barstow ayg bugs contributor ian julian.reschke mike public-webapps public-webapps-bugzilla oldest_to_newest 47505 0 glenn 2011-04-16 02:11:08 +0000 As presently defined, WebSocket may establish a connection before onopen is set. Using the example found in Section 4: var socket = new WebSocket('ws://game.example.com:12010/updates'); socket.onopen = function () { setInterval(function() { if (socket.bufferedAmount == 0) socket.send(getUpdateData()); }, 50); }; In this case, the new websocket may transition to OPEN state prior to execution of the statement that sets the onopen property. For instance, this may occur when stepping through this JS code in a JS debugger, or when GC occurs between the constructor and the following statement. The WS API should be modified to separate construction from opening, e..g., following a paradigm similar to XHR in which case the above example would become: var socket = new WebSocket(); socket.onopen = function () { setInterval(function() { if (socket.bufferedAmount == 0) socket.send(getUpdateData()); }, 50); }; socket.open('ws://game.example.com:12010/updates'); Regards, Glenn Adams 47805 1 zcorpan 2011-04-29 14:23:08 +0000 There's no race condition. The spec queues a task to fire 'open', so even if the connection is established before the script has finished running, the event isn't fired until the event loop spins. Adding .open() doesn't help since we'd still want there to be no race condition if open() is called before setting the listener (since authors are going to do that). 48746 2 bugs 2011-05-24 19:14:02 +0000 Yeah, this is invalid, as far as I see. 48748 3 glenn 2011-05-24 20:09:39 +0000 (In reply to comment #2) > Yeah, this is invalid, as far as I see. I disagree. Notwithstanding the statement in 2.1 that "Many fundamental concepts from HTML are used by this specification. [HTML]", the current WebSocket spec does not normatively reference the task, task queue, or task dispatch semantics defined by HTML5. If the constraints on task semantics that are defined by HTML5 are required to prevent deadlocks in WebSocket, then WebSocket must normatively reference the definitions of task, task queue, and task dispatching semantics defined in HTML5. Otherwise, WebSocket is underspecified and an arbitrary implementation (that does not happen to employ the HTML5 constraints) may indeed be deadlocked. Regards, Glenn 48757 4 ian 2011-05-24 23:43:50 +0000 The sentence you quote is that normative reference. You're better off reading the spec in its full form where those terms are just part of the spec, anyway; the W3C copy is just an extract of the full spec. The full spec is here: http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#network 48762 5 glenn 2011-05-25 04:22:17 +0000 (In reply to comment #4) > The sentence you quote is that normative reference. > > You're better off reading the spec in its full form where those terms are just > part of the spec, anyway; the W3C copy is just an extract of the full spec. The > full spec is here: > > > http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#network I'm sorry, but I do not recognize the role of WhatWG in terms of defining normative W3C specifications. The sentence I quoted is insufficient since it does not cite which normative definitions of HTML5 apply. At present, this results in WebSocket being "not-well-defined". Regards, Glenn 48825 6 ayg 2011-05-25 22:42:42 +0000 It looks like the script that splits up the spec doesn't make cross-spec references into links. This seems like a bug in the spec-splitter, which could be confusing, since the writing style of HTML5 relies heavily on xrefs to make its meaning clear. Specs like DOM Range do cross-spec xrefs just fine, so no reason HTML5-related specs shouldn't. 48871 7 ayg 2011-05-27 17:13:05 +0000 Changed summary to make it clear this is a question of bugs in the spec-splitter, not a bug in the original source text. In this specific case, the terms used are pretty distinctive, and if you know they're defined in HTML5 (which this spec normatively references) you'll be able to find them, so it's not really very ambiguous in the end. But it could be confusing to someone who's not so familiar with HTML5. 48873 8 glenn 2011-05-27 17:40:44 +0000 (In reply to comment #7) > Changed summary to make it clear this is a question of bugs in the > spec-splitter, not a bug in the original source text. In this specific case, > the terms used are pretty distinctive, and if you know they're defined in HTML5 > (which this spec normatively references) you'll be able to find them, so it's > not really very ambiguous in the end. But it could be confusing to someone > who's not so familiar with HTML5. Please note also that there is a circular reference between HTML5 and WebSockets, since the former normatively references the latter and the latter normatively references the former. This is rather unsatisfactory in formal spec writing. It is best to have a non-circular dependency graph. 48874 9 ayg 2011-05-27 17:49:55 +0000 If you think that's an issue, you should probably file a separate bug. As far as I'm aware, it's allowed by W3C Process: they'd just have to progress to PR at the same time. 51185 10 ayg 2011-07-17 14:29:22 +0000 *** Bug 13280 has been marked as a duplicate of this bug. *** 59336 11 ian 2011-10-31 22:47:58 +0000 I have no intention of adding cross-spec cross-references to the WebSocket spec. If someone is interested in providing patches to the spec splitter to do this, please contact me directly. 59770 12 glenn 2011-11-09 02:12:32 +0000 (In reply to comment #11) > I have no intention of adding cross-spec cross-references to the WebSocket > spec. If someone is interested in providing patches to the spec splitter to do > this, please contact me directly. How you create your spec products for use in the W3C is your business, not mine. I am asking that each reference or use of a "fundamental concept" as described in 2.1: "Many fundamental concepts from HTML are used by this specification. [HTML]" be made explicit by using a link (anchor) to the relevant defining clause/section in [HTML]. For example, the following phrases should link to the defining sections of [HTML]: 1. "queue a task" => http://dev.w3.org/html5/spec/Overview.html#queue-a-task 2. "dispatch [an] event" => http://dev.w3.org/html5/spec/Overview.html#concept-event-dispatch 3. "task source" => http://dev.w3.org/html5/spec/Overview.html#task-source 4. "event loop" => http://dev.w3.org/html5/spec/Overview.html#event-loop 5. "task" (otherwise unqualified) => http://dev.w3.org/html5/spec/Overview.html#concept-task If these (and any other "concepts from HTML" I don't list above) are used normatively, then it should be made clear that the HTML definition applies (and not some other random implied definition). I don't care if it is done by links at each usage, or by listing the concepts in one place (e.g., under dependencies) and placing the links there. 60780 13 ian 2011-12-02 16:48:33 +0000 I understand what you're asking for. I'm saying that if you want it any time soon, you need to provide the script to set it up. Failing that, it'll have to wait until I get around to it, which may not be for some time as I don't really have a good idea for how to do it. 60790 14 julian.reschke 2011-12-02 17:19:16 +0000 This is indeed a problem. The W3C version is incomplete/underspecified without these terms being properly linked (note that a similar issue has been raised by me with respect to "URL" parsing during WGLC). 60876 15 ian 2011-12-03 02:54:27 +0000 If you want the hyperlinks, use the WHATWG version. It's the same text. Hyperlinks cannot possibly be required for the content to make sense, by the way, otherwise we'd never be able to print the spec. That just makes no sense. 60890 16 julian.reschke 2011-12-03 09:28:05 +0000 (In reply to comment #15) > If you want the hyperlinks, use the WHATWG version. It's the same text. This bug isn't about the WHATWG spec. The *published* W3C spec needs to be complete and well-defined. Somebody will have to take care of this. (And yes, it's your right to not care, in which the W3C should assign somebody else to fix it). > Hyperlinks cannot possibly be required for the content to make sense, by the > way, otherwise we'd never be able to print the spec. That just makes no sense. What's essential is that's clear what certain text means. Hyperlinking it is one way for HTML. For a print version, external links could be inlined as visibile text. Also, with respect to printing, internal links have the same problem. 69817 17 ian 2012-07-10 22:36:31 +0000 If the W3C does "assign somebody else to fix it", I'd be happy to work with them. So if anyone wants to do that, drop me a private e-mail and I'll set you up with the right files to edit, etc. 69868 18 julian.reschke 2012-07-12 05:35:10 +0000 See <http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0104.html> for a patch applicable to the W3C version of the spec. 77166 19 ian 2012-10-26 23:35:42 +0000 That patch is unhelpful since it is to a dynamically generated file. Hence my comment 17. I'm marking this WONTFIX, since I view the WHATWG version as canonical and don't really think it's a problem for people to use the WHATWG version. The W3C version is only useful for the patent policy, and thus doesn't need the hyperlinks. However, I wouldn't object to someone finding a solution to this. If anyone does want to actually work with me to fix this, please reopen the bug, assign it to yourself, and e-mail me, as per comment 17. Thanks. 77179 20 glenn 2012-10-27 05:18:33 +0000 I'm unable to accept this resolution, in part because this is a W3C venue and, as a consequence, the W3C version of HTML5 is canonical, not WHATWG. It is the responsibility of the spec writer to define or referenced external definition of formal terms, and that responsibility applies here. 77331 21 ian 2012-10-29 21:50:49 +0000 I'm not going to be doing it, if you want to do it you are welcome to work with Art to do so. Reassigning it to you to get it off my radar. The W3C versions of these specs are not their canonical versions, whether for Web Sockets or for HTML, as far as I am concerned.