Re: [XHR] test nitpicks: MIME type / charset requirements
Aren't both text/html;charset=windows-1252 and text/html; charset=windows-1252 valid MIME types? Should we make the tests a bit more accepting? Reading http://www.w3.org/Protocols/rfc1341/4_Content-Type.html it's not crystal clear if spaces are accepted, although white spaces and space are clearly cited in the grammar as forbidden in tokens. My understanding is that the intent is for white spaces to be ignored but I could be wrong. Truth is the spec could use some consistency and precision. test script sets charset=utf-8 and charset=UTF-8 on the wire is considered a failure Those tests must ignore case. The type, subtype, and parameter names are not case sensitive. On 6 May 2013 18:31, Hallvord Reiar Michaelsen Steen hallv...@opera.comwrote: Two of the tests in http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-string.htmfails in Firefox just because there is a space before the word charset. Aren't both text/html;charset=windows-1252 and text/html; charset=windows-1252 valid MIME types? Should we make the tests a bit more accepting? Also, there's a test in http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-charset.htmthat fails in Chrome because it asserts charset must be lower case, i.e. test script sets charset=utf-8 and charset=UTF-8 on the wire is considered a failure. Does that make sense? -- Hallvord R. M. Steen Core tester, Opera Software
Re: [XHR] test nitpicks: MIME type / charset requirements
On Mon, May 6, 2013 at 9:31 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: ... The reason the tests test that is because the specification requires exactly that. If you want to change the tests, you'd first have to change the specification. (What HTTP says on the matter is not relevant.) -- http://annevankesteren.nl/
Re: [XHR] test nitpicks: MIME type / charset requirements
Hey Anne, I don't quite get why you're saying HTTP is irrelevant. As an example, regarding the content-type *request *header, the XHR spec clearly states: If a Content-Type header is in author request headershttp://www.w3.org/TR/XMLHttpRequest/#author-request-headers and its value is a valid MIME typehttp://dev.w3.org/html5/spec/infrastructure.html#valid-mime-type that has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all thecharset parameters of that Content-Type header to encoding. So, at least, the encoding in the request content-type is clearly stated as being case-insensitive. BTW, Valid MIME type leads to (HTML 5.1): A string is a valid MIME type if it matches the media-type rule defined in section 3.7 Media Types of RFC 2616. In particular, a valid MIME typehttp://www.w3.org/html/wg/drafts/html/master/infrastructure.html#valid-mime-type may include MIME type parameters. [HTTP]http://www.w3.org/html/wg/drafts/html/master/iana.html#refsHTTP Of course, nothing is explicitely specified regarding the *response *content-type, because it is implicitely covered by HTTP (seeing as the value is generated outside of the client -- except when using overrideMimeType). It's usage as defined by the XHR spec is irrelevant to the fact it is to be considered case-insensitively : any software or hardware along the network path is perfectly entitled to change the case of the Content-Type header because HTTP clearly states case does not matter. So, testing for a response Content-Type case-sensitively is *not *correct. Things are less clear to me when it comes to white spaces. I find HTTP quite evasive on the matter. Please, correct me if I'm wrong and feel free to point me to the exact sentences in the XHR spec that calls for an exception regarding case-insensitivity of MIME types (as defined in HTTP which XHR references through HTML 5.1). I may very well have missed those. Cheers, -- Julian On 6 May 2013 19:22, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 9:31 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: ... The reason the tests test that is because the specification requires exactly that. If you want to change the tests, you'd first have to change the specification. (What HTTP says on the matter is not relevant.) -- http://annevankesteren.nl/
Re: [XHR] test nitpicks: MIME type / charset requirements
On Mon, May 6, 2013 at 3:44 PM, Julian Aubourg j...@ubourg.net wrote: I don't quite get why you're saying HTTP is irrelevant. For the requirements where the XMLHttpRequest says to put a certain byte string as a value of a header, that's what the implementation has to do, and nothing else. We could make the XMLHttpRequest talk about the value in a more abstract manner rather than any particular serialization and leave the serialization undefined, but it's not clear we should do that. As an example, regarding the content-type request header, the XHR spec clearly states: If a Content-Type header is in author request headers and its value is a valid MIME type that has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of that Content-Type header to encoding. Yeah, this part needs to be updated at some point to actually state what should happen in terms of parsing and such, but for now it's clear enough. So, testing for a response Content-Type case-sensitively is not correct. It is if the specification requires a specific byte string as value. Things are less clear to me when it comes to white spaces. I find HTTP quite evasive on the matter. You can have a space there, but not per the requirements in XMLHttpRequest. -- http://annevankesteren.nl/
Re: [XHR] test nitpicks: MIME type / charset requirements
You made the whole thing a lot clearer to me, thank you :) It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? It seems to me they promote bad practice (case-sensitive testing of Content-Type). On 7 May 2013 01:20, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 3:44 PM, Julian Aubourg j...@ubourg.net wrote: I don't quite get why you're saying HTTP is irrelevant. For the requirements where the XMLHttpRequest says to put a certain byte string as a value of a header, that's what the implementation has to do, and nothing else. We could make the XMLHttpRequest talk about the value in a more abstract manner rather than any particular serialization and leave the serialization undefined, but it's not clear we should do that. As an example, regarding the content-type request header, the XHR spec clearly states: If a Content-Type header is in author request headers and its value is a valid MIME type that has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of that Content-Type header to encoding. Yeah, this part needs to be updated at some point to actually state what should happen in terms of parsing and such, but for now it's clear enough. So, testing for a response Content-Type case-sensitively is not correct. It is if the specification requires a specific byte string as value. Things are less clear to me when it comes to white spaces. I find HTTP quite evasive on the matter. You can have a space there, but not per the requirements in XMLHttpRequest. -- http://annevankesteren.nl/
Re: [XHR] test nitpicks: MIME type / charset requirements
On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote: It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? It seems to me they promote bad practice (case-sensitive testing of Content-Type). There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). 1. Require the same from everyone. 2. Require randomness. Anything else is likely to lead some subset of developers to depend on certain things they really should not depend on and will force everyone to match the conventions of what they depend on (if you're in bad luck you'll get mutual exclusive dependencies; the web has those too). E.g. the ordering of the members of the canvas element is one such thing (trivial bad luck example is User-Agent). -- http://annevankesteren.nl/
Re: [XHR] test nitpicks: MIME type / charset requirements
I hear you, but isn't having a case-sensitive value of Content-Type *in certain circumstances* triggering the kind of problem you're talking about (developers to depend on certain things they really should not depend on) ? As I see it, the tests in question here are doing something that is wrong in the general use-case from an author's POW. By requiring the same from every *implementor*, aren't we pushing *authors *in the trap you describe. Case in point : the author of the test is testing Content-Type case-sensitively while it is improper (from an author POW) in any other circumstance. The same code will fail if, say, the server sets a Content-Type. Shouldn't we protect authors from such inconsistencies ? On 7 May 2013 01:39, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote: It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? It seems to me they promote bad practice (case-sensitive testing of Content-Type). There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). 1. Require the same from everyone. 2. Require randomness. Anything else is likely to lead some subset of developers to depend on certain things they really should not depend on and will force everyone to match the conventions of what they depend on (if you're in bad luck you'll get mutual exclusive dependencies; the web has those too). E.g. the ordering of the members of the canvas element is one such thing (trivial bad luck example is User-Agent). -- http://annevankesteren.nl/
Re: [XHR] test nitpicks: MIME type / charset requirements
On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote: It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? This is how the web is rings like an 'argument from authority'. I'm generally less concerned about those than I believe you are, but I think Julien's questions here are important. It seems to me they promote bad practice (case-sensitive testing of Content-Type). There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). (maybe.) 1. Require the same from everyone. So is there a concrete dominanant implementation that is case-sensitive? Because requiring case-insensistive matching from everyone would seem to meet your requirement above, in principle. And it might even be that with good clear specifications and good test suites that the dominant implementation reinforces a simpler path for authors. Anything else is likely to lead some subset of developers to depend on certain things they really should not depend on and will force everyone to match the conventions of what they depend on I know this has happened on the web for various cases. But it actually depends on having a sufficiently non-conformant implementation be sufficiently important to dominate (rather than be a known error case that is commonly monkey-patched until in a decade or so it just evaporates). I don't see any proof that it is *bound* to happen. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
RE: [XHR] test nitpicks: MIME type / charset requirements
Since XHR is the API to facilitate a valid HTTP transaction, IMHO, it should be fully compliant with HTTP - no more and no less. A valid HTTP request and response should be interpreted consistently across UA's and devices. Interoperability is very important across UA's and devices. If the XHR, either spec or implementation, is not fully compliant with HTTP, it will give users an unpleasant experience resulting from the interoperability issue. Thanks Bin -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Monday, May 06, 2013 6:06 PM To: Julian Aubourg; Anne van Kesteren Cc: Hallvord Reiar Michaelsen Steen; public-webapps WG Subject: Re: [XHR] test nitpicks: MIME type / charset requirements On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote: It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? This is how the web is rings like an 'argument from authority'. I'm generally less concerned about those than I believe you are, but I think Julien's questions here are important. It seems to me they promote bad practice (case-sensitive testing of Content-Type). There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). (maybe.) 1. Require the same from everyone. So is there a concrete dominanant implementation that is case-sensitive? Because requiring case-insensistive matching from everyone would seem to meet your requirement above, in principle. And it might even be that with good clear specifications and good test suites that the dominant implementation reinforces a simpler path for authors. Anything else is likely to lead some subset of developers to depend on certain things they really should not depend on and will force everyone to match the conventions of what they depend on I know this has happened on the web for various cases. But it actually depends on having a sufficiently non-conformant implementation be sufficiently important to dominate (rather than be a known error case that is commonly monkey-patched until in a decade or so it just evaporates). I don't see any proof that it is *bound* to happen. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
[Bug 21650] New: Require that XHR is available in workers
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21650 Bug ID: 21650 Summary: Require that XHR is available in workers Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: sim...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://xhr.spec.whatwg.org/#interface-xmlhttprequest This used to be in the worker spec but was removed at some point. The XHR spec needs to say something like [[ The XMLHttpRequest constructor must be exposed if the JavaScript global environment is a worker environment. ]] see e.g. http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#workernavigator Similarly for all other interfaces you want to be exposed in workers defined in this spec. -- You are receiving this mail because: You are on the CC list for the bug.
[admin] Towards XHR The Attorney's Edition
Last year we agreed to stop work on the baseline XHR spec because no
one was willing to work on that version of the spec. Since then, the new
XHR Editors agreed to work on a baseline version as well as to continue
to work on the `bleeding edge` version.
One goal of the baseline version is to specify features that are widely
implemented and deployed today. As such, it _should_ be relatively
straight forward to move this version to LC and then to CR-PR-REC and
thus finalize the IP commitments by WebApps' members. (There are no
firm IP commitments for XHR until a REC is published.)
My proposal is to use the XMLHttpRequest1 shortname for the baseline
version, the same shortname as the XHR WG Note published 17 January 2012
[XHR-Note]. Thus, the first TR publication of the new baseline spec
would replace the WG Note (although the dated version of the WG Note
[XHR-Note-Dated] will of course be untouched).
I don't feel strongly about the title of the baseline version. Some
options: XMLHttpRequest Baseline, XMLHttpRequest Level {0,1} and I
could live with something like XMLHttpRequest: The Attorney's Edition
[v{0,1}].
Comments?
-Art and Chaals
[XHR-Note] http://www.w3.org/TR/XMLHttpRequest1/
[XHR-Note-Dated] http://www.w3.org/TR/2012/NOTE-XMLHttpRequest1-20120117/
Re: [admin] Towards XHR The Attorney's Edition
On Thu, 28 Feb 2013 15:46:34 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
Last year we agreed to stop work on the baseline XHR spec because no
one was willing to work on that version of the spec. Since then, the new
XHR Editors agreed to work on a baseline version as well as to continue
to work on the `bleeding edge` version.
One goal of the baseline version is to specify features that are widely
implemented and deployed today. As such, it _should_ be relatively
straight forward to move this version to LC and then to CR-PR-REC and
thus finalize the IP commitments by WebApps' members. (There are no
firm IP commitments for XHR until a REC is published.)
My proposal is to use the XMLHttpRequest1 shortname for the baseline
version, the same shortname as the XHR WG Note published 17 January 2012
[XHR-Note]. Thus, the first TR publication of the new baseline spec
would replace the WG Note (although the dated version of the WG Note
[XHR-Note-Dated] will of course be untouched).
I don't feel strongly about the title of the baseline version. Some
options: XMLHttpRequest Baseline, XMLHttpRequest Level {0,1} and I
could live with something like XMLHttpRequest: The Attorney's Edition
[v{0,1}].
Comments?
Much as I love it, I don't think The attorney's edition is a helpful
addition to the title. Besides, I think it is valuable for people for
reasons other than just fulfilling the patent policy requirements.
Since we expect this to basically be the stuff in what used to be called
XMLHttpRequest level 1 that is actually widely implemented (ie really
standard, not just the things we think should be), I think XMLHttpRequest
level 1 makes a pretty sensible real name.
cheers
Chaals
-Art and Chaals
[XHR-Note] http://www.w3.org/TR/XMLHttpRequest1/
[XHR-Note-Dated]
http://www.w3.org/TR/2012/NOTE-XMLHttpRequest1-20120117/
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: [XHR] remove user cancels request
can i ask, how do you use the abort event handler? and error event handler In jQuery 1.x, we don't even use onsuccess, onerror and onabort. Reason being onreadystatechange is the only cross-browser means to handle XMLHttpRequest when you have to support old IEs (and we try and avoid having multiple code paths in jQuery because of size, maintainability and behavioural consistency). In jQuery 2.x, we use onload and onerror, not onabort. We have some short-circuit logic in $.ajax to notify author's initiated aborts as errors with a cancelled status but we ignore all other sources of aborts. The idea is to ignore onunload aborts so that jQuery devs don't have to special case for it in their error handlers. Now, to get back to the subject at hand, like Glenn said, it's probably better to notify those not-author-initiated aborts as errors, because from the author's POW they're hardly aborts. However, if we do so, we have to make sure it's possible to differentiate them from a network error. jQuery, as an author, can then choose to ignore them or bubble them up in $.ajax, not sure what's best for us at this point but that's another story entirely.
Re: [XHR] remove user cancels request
I have the same questions as Jungkee. What is it you want to remove exactly? Why do you think the distinction between an user-initiated abort and a network error is irrelevant? If I am to believe jQuery's bug tracker, our users want and need the distinction. On 25 February 2013 07:49, Jungkee Song jungkee.s...@samsung.com wrote: From: Timmy Willison [mailto:timmywill...@gmail.com] Sent: Monday, February 25, 2013 2:55 AM On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). According to the current spec, it is already the case that onabort() is called only when client.abort() is explicitly called (including CORS requests.) onerror() is getting called in actual network errors such as DNS error, TLS negotiation failure, cross-origin access violation, etc. I am not sure what conditions Anne exactly propose to remove from the spec. I can think of only three scenarios where the end user *terminates* the request: calling open(), calling abort() or explicitly stop in browser chrome. I don't think client.open() and explicit browser stop are what Anne is talking about. Anne, could you elaborate what part of the text are you pointing? If it's the case that you want to merge abort into error, I tend to disagree as there can be use cases explicitly putting cancel button in UI that should be distinguished from network initiated errors. Jungkee +1 -- Glenn Maynard - Timmy
Re: [XHR] remove user cancels request
On Mon, Feb 25, 2013 at 8:20 AM, Julian Aubourg j...@ubourg.net wrote: I have the same questions as Jungkee. What is it you want to remove exactly? Why do you think the distinction between an user-initiated abort and a network error is irrelevant? If I am to believe jQuery's bug tracker, our users want and need the distinction. Euhm. My email said end user (which the spec simply calls users, jQuery's users are called authors/developers). If you search for This is an abort error you'll find the bits I think can be removed due to lack of browser UI for that feature. -- http://annevankesteren.nl/
Re: [XHR] remove user cancels request
AFAIK, clicking the stop button of the navigator or clicking on a link in the page will abort outbound requests. That's exactly the kind of aborts authors want to differentiate from network errors. I assume those buttons are UI features that permit request cancellation for users? Or am I completly missing the point again? On 25 February 2013 10:08, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Feb 25, 2013 at 8:20 AM, Julian Aubourg j...@ubourg.net wrote: I have the same questions as Jungkee. What is it you want to remove exactly? Why do you think the distinction between an user-initiated abort and a network error is irrelevant? If I am to believe jQuery's bug tracker, our users want and need the distinction. Euhm. My email said end user (which the spec simply calls users, jQuery's users are called authors/developers). If you search for This is an abort error you'll find the bits I think can be removed due to lack of browser UI for that feature. -- http://annevankesteren.nl/
Re: [XHR] remove user cancels request
On Mon, Feb 25, 2013 at 9:22 AM, Julian Aubourg j...@ubourg.net wrote: AFAIK, clicking the stop button of the navigator or clicking on a link in the page will abort outbound requests. That's exactly the kind of aborts authors want to differentiate from network errors. I assume those buttons are UI features that permit request cancellation for users? Or am I completly missing the point again? Sure, for links (i.e. navigation)... For XMLHttpRequest (fetching) however those rarely change as that would make applications very confusing to the user. At least, when I still worked at Opera at some point the progress bars for fetching after the page had loaded (body load fired) were disabled as they were just too confusing. -- http://annevankesteren.nl/
Re: [XHR] remove user cancels request
On Mon, Feb 25, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote: Sure, for links (i.e. navigation)... For XMLHttpRequest (fetching) however those rarely change as that would make applications very confusing to the user. At least, when I still worked at Opera at some point the progress bars for fetching after the page had loaded (body load fired) were disabled as they were just too confusing. Some data points: - Firefox already sends onerror if you hit escape while an XHR is in progress. The onerror handler can just start another XHR request, and pressing escape again will once again onerror that new request. - In WebKit, if the document load is still in progress, escape cancels both the document load (eg. images) and any running XHRs. If this happens, onabort is sent to the request. However, this only happens during initial document load; after that, XHR requests can't be cancelled. The onabort handler can also start another XHR, and since the document load is no longer in progress, this one can't be cancelled. - IE9 doesn't seem to abort XHR at all. WebKit's behavior doesn't make sense. Firefox's behavior seems to match what you're suggesting, and it's what I'd expect. Since it doesn't expose any code paths that can't happen otherwise, it should also result in the least chance of bugs. IE9's behavior of not cancelling XHR on escape at all seems reasonable, too. For navigation, - Firefox also fires onerror if you navigate while an XHR is in progress. - WebKit fires onabort. - IE9 doesn't seem to cancel XHR on navigation. (You can get an XHR onload after the user has already clicked a link, if the new page hasn't already begun to load.) If authors really want to be able to distinguish a user cancellation from a regular network error, let's stick a flag on onerror. It's much worse to have to carefully distinguish abort() from a user abort. They're completely different things. -- Glenn Maynard
Re: [XHR] remove user cancels request
I agree with Glenn that these user cancellations would be better notified
as errors rather than aborts. Key here is to make it possible for authors
to know what's going on and onabort seems quite confusing.
Side note: IE not cancelling requests is a real pain, we have to abort
manually on unload in jQuery because, in old IEs when using the
ActiveX-based XHRs those pending requests may end up exhausting the pool of
available XHRs!
Le lundi 25 février 2013, Glenn Maynard a écrit :
On Mon, Feb 25, 2013 at 3:37 AM, Anne van Kesteren
ann...@annevk.nljavascript:_e({}, 'cvml', 'ann...@annevk.nl');
wrote:
Sure, for links (i.e. navigation)... For XMLHttpRequest (fetching)
however those rarely change as that would make applications very
confusing to the user. At least, when I still worked at Opera at some
point the progress bars for fetching after the page had loaded (body
load fired) were disabled as they were just too confusing.
Some data points:
- Firefox already sends onerror if you hit escape while an XHR is in
progress. The onerror handler can just start another XHR request, and
pressing escape again will once again onerror that new request.
- In WebKit, if the document load is still in progress, escape cancels
both the document load (eg. images) and any running XHRs. If this happens,
onabort is sent to the request. However, this only happens during initial
document load; after that, XHR requests can't be cancelled. The onabort
handler can also start another XHR, and since the document load is no
longer in progress, this one can't be cancelled.
- IE9 doesn't seem to abort XHR at all.
WebKit's behavior doesn't make sense.
Firefox's behavior seems to match what you're suggesting, and it's what
I'd expect. Since it doesn't expose any code paths that can't happen
otherwise, it should also result in the least chance of bugs.
IE9's behavior of not cancelling XHR on escape at all seems reasonable,
too.
For navigation,
- Firefox also fires onerror if you navigate while an XHR is in progress.
- WebKit fires onabort.
- IE9 doesn't seem to cancel XHR on navigation. (You can get an XHR
onload after the user has already clicked a link, if the new page hasn't
already begun to load.)
If authors really want to be able to distinguish a user cancellation from
a regular network error, let's stick a flag on onerror. It's much worse to
have to carefully distinguish abort() from a user abort. They're
completely different things.
--
Glenn Maynard
Re: [XHR] remove user cancels request
Hello On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. Chrome(WebKit) and Firefox has ability to abort XHR requests:With ESC key (in chrome it works while page is loading), also XHR is aborted while page unloading.Chrome fires “abort”Firefox fires “error” In Firefox I can not distinguish network error from users abort(workarounds with page unloading detection will NOT work), but I have to show a warning message to the user when there is a network error. I think, that “abort” event is FOR that case.this situation should be clearly spelled out in the spec 1
Re: [XHR] remove user cancels request
Key here is to make it possible for author to know what's going on and onabort seems quite confusing can i ask, how do you use the "abort" event handler?and "error" event handler" in case of user abort, it is not good to reconnect or show warningbut in case of error, it is good
[XHR] remove user cancels request
Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ -- http://annevankesteren.nl/
Re: [XHR] remove user cancels request
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). -- Glenn Maynard
Re: [XHR] remove user cancels request
On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). +1 -- Glenn Maynard - Timmy
RE: [XHR] remove user cancels request
From: Timmy Willison [mailto:timmywill...@gmail.com] Sent: Monday, February 25, 2013 2:55 AM On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). According to the current spec, it is already the case that onabort() is called only when client.abort() is explicitly called (including CORS requests.) onerror() is getting called in actual network errors such as DNS error, TLS negotiation failure, cross-origin access violation, etc. I am not sure what conditions Anne exactly propose to remove from the spec. I can think of only three scenarios where the end user *terminates* the request: calling open(), calling abort() or explicitly stop in browser chrome. I don't think client.open() and explicit browser stop are what Anne is talking about. Anne, could you elaborate what part of the text are you pointing? If it's the case that you want to merge abort into error, I tend to disagree as there can be use cases explicitly putting cancel button in UI that should be distinguished from network initiated errors. Jungkee +1 -- Glenn Maynard - Timmy
[Bug 17046] Implement redirect audit functionality for XHR
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17046 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Anne ann...@annevk.nl --- *** This bug has been marked as a duplicate of bug 12607 *** -- You are receiving this mail because: You are on the CC list for the bug.
[xhr] Appending a charset after an author added content-type
Hi, Nicolas Chambrier (he's not registered to the list, please keep him in the CC in your replies) and I came across that case recently: 1) create an XHR object (POST in case it matters) 2) set the Content-Type header explicitly (it changes, but we noticed it with something like application/vnd.ooz.user.v1+json) 3) .send() (what is sent is a JSON valid string) Firefox adds a ; charset=UTF-8 after the manually set content-type value. Chrome does not. I'd like to report a bug, but I'm not sure where I should report it to :-s My understanding of the spec is that the charset shouldn't be added, because: 1) the Content-Type header is in author request header 2) the value is a valid MIME-type (tell me if I'm wrong on this) 3) it does not have a charset parameter (so, the condition of step 4 doesn't apply in my opinion). Who should I file a bug against? David
Re: [xhr] Appending a charset after an author added content-type
On Tue, Feb 19, 2013 at 5:51 PM, David Bruant bruan...@gmail.com wrote: My understanding of the spec is that the charset shouldn't be added, because: 1) the Content-Type header is in author request header 2) the value is a valid MIME-type (tell me if I'm wrong on this) 3) it does not have a charset parameter (so, the condition of step 4 doesn't apply in my opinion). Who should I file a bug against? Firefox. http://xhr.spec.whatwg.org/#the-send%28%29-method is pretty clear that we only correct charset parameters. Even if application/vnd.ooz.user.v1+json was invalid we still should not muddle with it. -- http://annevankesteren.nl/
Re: [xhr] Appending a charset after an author added content-type
On 2/19/13 1:40 PM, Anne van Kesteren wrote: On Tue, Feb 19, 2013 at 5:51 PM, David Bruant bruan...@gmail.com wrote: My understanding of the spec is that the charset shouldn't be added, because: 1) the Content-Type header is in author request header 2) the value is a valid MIME-type (tell me if I'm wrong on this) 3) it does not have a charset parameter (so, the condition of step 4 doesn't apply in my opinion). Who should I file a bug against? Firefox. http://xhr.spec.whatwg.org/#the-send%28%29-method is pretty clear that we only correct charset parameters. Even if application/vnd.ooz.user.v1+json was invalid we still should not muddle with it. Note that Firefox adds the charset even if it wasn't set by the page because web developers were asking for it to aid server-side processing... The alternative is that the server has no idea what to do with the data. :( -Boris
Re: [xhr] Appending a charset after an author added content-type
On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: Note that Firefox adds the charset even if it wasn't set by the page because web developers were asking for it to aid server-side processing... The alternative is that the server has no idea what to do with the data. :( Does that include cases though where the page did set a Content-Type through setRequestHeader()? Because technically what Firefox does violates HTTP semantics as not every MIME type allows for a charset parameter. -- http://annevankesteren.nl/
Re: [xhr] Appending a charset after an author added content-type
On 2013-02-19 19:51, Anne van Kesteren wrote: On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: Note that Firefox adds the charset even if it wasn't set by the page because web developers were asking for it to aid server-side processing... The alternative is that the server has no idea what to do with the data. :( Does that include cases though where the page did set a Content-Type through setRequestHeader()? Because technically what Firefox does violates HTTP semantics as not every MIME type allows for a charset parameter. Right. If other UAs don't do this, FF should avoid it as well. Which reminds me about the funny requirement to rewrite charset parameters in place; this really needs test cases; if it's still only Firefox doing it it should be nuked from the spec. Best regards, Julian
Re: [xhr] Appending a charset after an author added content-type
On 2/19/13 1:51 PM, Anne van Kesteren wrote: Does that include cases though where the page did set a Content-Type through setRequestHeader()? That's a good question. I don't remember anymore; I'd have to go read the relevant bugs. Because technically what Firefox does violates HTTP semantics as not every MIME type allows for a charset parameter. Indeed. Not sure how worthwhile it is to restrict this sort of thing to text/plain. -Boris
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 8:00 PM, Anne van Kesteren ann...@annevk.nl wrote: Hmm I see what you mean. But the user agent can provide the Authorization header too based on a previous visit. That is the meaning that is most often meant, but in the particular case of CORS the semantics are subtly different. Not sure how to clarify that exactly. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013 -- http://annevankesteren.nl/
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain mon...@gmail.com wrote: The XHR spec defines user credentials as cookies, HTTP authentication, and client-side SSL certificates. Its not clear to me what HTTP authentication referring to. I assumed it was referring to the HTTP authentication in RFC 2617, which uses the Authorization header. But a quick test shows that arbitrary Authorization headers are allowed on CORS requests. It could also mean the http://username@password:domain.com form of authentication (not sure where this is formally defined). What type of http authentication is the XHR spec referring to? User credentials stored by the user agent based on a previous visit to the URL. Authorization is only allowed through CORS if the server opts in, btw. These details should become more clear once I turn http://wiki.whatwg.org/wiki/Fetch into a proper specification. -- http://annevankesteren.nl/
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain mon...@gmail.com wrote: The XHR spec defines user credentials as cookies, HTTP authentication, and client-side SSL certificates. Its not clear to me what HTTP authentication referring to. I assumed it was referring to the HTTP authentication in RFC 2617, which uses the Authorization header. But a quick test shows that arbitrary Authorization headers are allowed on CORS requests. It could also mean the http://username@password:domain.com form of authentication (not sure where this is formally defined). What type of http authentication is the XHR spec referring to? User credentials stored by the user agent based on a previous visit to the URL. Ok thanks. I think it would be useful if the HTTP authentication in the above sentence snippet were either dropped or clarified (The CORS spec also uses the same sentence). Authorization is only allowed through CORS if the server opts in, btw. These details should become more clear once I turn http://wiki.whatwg.org/wiki/Fetch into a proper specification. -- http://annevankesteren.nl/
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain mon...@gmail.com wrote: On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote: User credentials stored by the user agent based on a previous visit to the URL. Ok thanks. I think it would be useful if the HTTP authentication in the above sentence snippet were either dropped or clarified (The CORS spec also uses the same sentence). How is it different from mentioning cookies? It has the same effect, no? -- http://annevankesteren.nl/
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 1:36 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain mon...@gmail.com wrote: On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote: User credentials stored by the user agent based on a previous visit to the URL. Ok thanks. I think it would be useful if the HTTP authentication in the above sentence snippet were either dropped or clarified (The CORS spec also uses the same sentence). How is it different from mentioning cookies? It has the same effect, no? I think what was confusing to me is that the Access-Control-Allow-Credentials section of the CORS spec indicates that a true value indicates that the actual request can include user credentials. In the case of cookies, both the client's .withCredentials and the server's Access-Control-Allow-Credentials must be true in order for the user-agent to return the response to the client. But in the case of the Authorization header, the server's opt-in mechanism is Access-Control-Allow-Headers, and has no connection to Access-Control-Allow-Credentials. The sentence above reads as if cookies and HTTP Authentication are both governed by the Access-Control-Allow-Credentials header, which is not the case in practice. Note that I am assuming that HTTP Authentication is referring to RFC 2617 and the use of the Authorization header. But the definition for user credentials in the Terminology section of the CORS spec doesn't say either way. If this is the case, there should be a reference to RFC 2617 in the Terminology section (Next to [COOKIES]). And if this is not the case, there should be more information to disambiguate the term HTTP Authentication from RFC2617. Thanks, Monsur -- http://annevankesteren.nl/
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 7:52 PM, Monsur Hossain mon...@gmail.com wrote: I think what was confusing to me is that the Access-Control-Allow-Credentials section of the CORS spec indicates that a true value indicates that the actual request can include user credentials. In the case of cookies, both the client's .withCredentials and the server's Access-Control-Allow-Credentials must be true in order for the user-agent to return the response to the client. But in the case of the Authorization header, the server's opt-in mechanism is Access-Control-Allow-Headers, and has no connection to Access-Control-Allow-Credentials. Hmm I see what you mean. But the user agent can provide the Authorization header too based on a previous visit. That is the meaning that is most often meant, but in the particular case of CORS the semantics are subtly different. Not sure how to clarify that exactly. -- http://annevankesteren.nl/
Re: [File API] About Partial Blob Data, XHR and Streams API
On Jan 22, 2013, at 9:42 AM, Cyril Concolato wrote: Hi Arun, Le 22/01/2013 15:04, Arun Ranganathan a écrit : Hi Cyril, 1) I'm wondering why in progressive mode, does the spec say: partial Blob data is an ArrayBuffer [TypedArrays] object consisting of the bytes loaded so far. Why isn't it the bytes loaded since the previous progress event? AR: It is always a new ArrayBuffer. The phraseology so far could be replaced by bytes loaded since the previous progress event though I'm not always sure that will be the case. I understood from Jonas' answer that it was a new ArrayBuffer. What remained unclear was the content of the ArrayBuffer: all the data from the beginning of the read operation (which was problematic), or only the data read since the previous progress event (which I prefer). If, as you say, this is latter option, then please fix the spec. as so far is very ambiguous. Hi Cyril: the model you propose, of deltas since the last read, is actually *not* what the spec's intent is. Your model does have advantages, but released software follows the former model, namely *all* the data since the beginning of the read operation. The partial results consist of all the bytes, starting from the beginning, but perhaps not the last byte, depending on progress event and file size. I'll have to clarify the prose, since from your question, it is clear that this isn't well described. -- A*
Re: [File API] About Partial Blob Data, XHR and Streams API
Hi Cyril, 1) I'm wondering why in progressive mode, does the spec say: partial Blob data is an ArrayBuffer [ TypedArrays ] object consisting of the bytes loaded so far . Why isn't it the bytes loaded since the previous progress event? AR: It is always a new ArrayBuffer. The phraseology so far could be replaced by bytes loaded since the previous progress event though I'm not always sure that will be the case. In my use case, the binary data resource might have an infinite size, in which case the result objects will grow forever. I looked at the Streams API [1] to see if there was any difference for that but I couldn't see any. Reading with the FileReader interface a Stream (dynamic length) or a Blob (fixed length) seems to always return the whole content. AR: Here, do you mean, you never get a progressevent other than load and loadend in your tests? Certainly, if you had binary data of infinite size, you'll get several result objects. The file API, particularly FileReader, shouldn't be used in streaming scenarios. -- A*
Re: [File API] About Partial Blob Data, XHR and Streams API
Hi Arun, Le 22/01/2013 15:04, Arun Ranganathan a écrit : Hi Cyril, 1) I'm wondering why in progressive mode, does the spec say: ||partial Blob data is an |ArrayBuffer|[TypedArrays http://dev.w3.org/2006/webapi/FileAPI/#TypedArrays] object consisting of the bytes|loaded|so far. Why isn't it the bytes loaded since the previous progress event? AR: It is always a new ArrayBuffer. The phraseology so far could be replaced by bytes loaded since the previous progress event though I'm not always sure that will be the case. I understood from Jonas' answer that it was a new ArrayBuffer. What remained unclear was the content of the ArrayBuffer: all the data from the beginning of the read operation (which was problematic), or only the data read since the previous progress event (which I prefer). If, as you say, this is latter option, then please fix the spec. as so far is very ambiguous. In my use case, the binary data resource might have an infinite size, in which case the result objects will grow forever. I looked at the Streams API [1] to see if there was any difference for that but I couldn't see any. Reading with the FileReader interface a Stream (dynamic length) or a Blob (fixed length) seems to always return the whole content. AR: Here, do you mean, you never get a progressevent other than load and loadend in your tests? No, I meant that the Streams API uses the same approach as the File API: This method should mimic|FileReader.readAsArrayBuffer()| http://dev.w3.org/2006/webapi/FileAPI/#readAsArrayBufferSyncSection So, I understood reading so far that you would get the content of the stream read so far from the beginning at each time, which is practically unusable. If the FileAPI spec is fixed, the Streams API is fixed as well. Certainly, if you had binary data of infinite size, you'll get several result objects. The file API, particularly FileReader, shouldn't be used in streaming scenarios. I disagree. The File API combined with XHR should be fine for reading (large) files for which the size is known when making the request but still delivered using HTTP streaming approaches. The Streams API and XHR should be fine for the same thing but for (infinite) files for which you don't know the size (chunked transfer to simulate IceCast/ShoutCast). A possible problem is when the apps want to receive the exact chunks created by the server (point 2 in my previous email) which the FileReader API doesn't preserve. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: [File API] About Partial Blob Data, XHR and Streams API
Hi Jonas, Le 1/18/2013 11:14 AM, Jonas Sicking a écrit : On Thu, Jan 17, 2013 at 1:56 AM, Cyril Concolato cyril.concol...@telecom-paristech.fr wrote: Hi all, Reading the File API, it is not clear to me what the behavior is when reading partial Blob data. The spec says: Partial Blob data is the part of the File or Blob that has been read into memory currently; when processing the read method readAsText, partial Blob data is a DOMString that is incremented as more bytes are loaded (a portion of the total) [ProgressEvents], and when processing readAsArrayBuffer partial Blob data is an ArrayBuffer [TypedArrays] object consisting of the bytes loaded so far (a portion of the total)[ProgressEvents]. Does this mean that the result object is the same or it is a new object each time there is a progress event ? In the case of a DOMString, it could be the same object incremented but if it is an ArrayBuffer, since it is immutable, it cannot be incremented. Strings in JS are immutable. So it will always be a new string. So in the case the final length of the Blob is not known yet (e.g. chunked XHR), result has to be a new object each time. Am I wrong here? If not, could you clarify the spec ? The size of a Blob is always known. The .size property never returns 'undefined' or 'null' or anything like that. XHR never returns a Blob object until it knows what size of Blob object to create. Thanks for the clarification. So if I understand correctly, the result attribute of a FileReader object at each progress event is a different object. Is that right? I also have a few more questions about the use of XHR and FileReader. The use case I'm working on is the HTTP Streaming of a live binary data (typically video and audio but not only) using chunked XHR. 1) I'm wondering why in progressive mode, does the spec say: ||partial Blob data is an |ArrayBuffer|[TypedArrays http://dev.w3.org/2006/webapi/FileAPI/#TypedArrays] object consisting of the bytes|loaded|so far. Why isn't it the bytes loaded since the previous progress event? In my use case, the binary data resource might have an infinite size, in which case the result objects will grow forever. I looked at the Streams API [1] to see if there was any difference for that but I couldn't see any. Reading with the FileReader interface a Stream (dynamic length) or a Blob (fixed length) seems to always return the whole content. I also looked at the WHATWG XHR spec [2] and its use of responseType stream and in this case, it seems that the response attribute is a Stream object containing the fragment of theentity body http://tools.ietf.org/html/rfc2616/#section-7.2of the response received so far. So this is not useful either. 2) I'm wondering also why wasn't the design made to enable accessing the content of each HTTP chunk directly within the XHR object. In a video streaming use case, the server might have carefully created the (video) chunks so that an application can use them independently without parsing them (typically passing them to the decoder through the MediaSource Extension API [3]). With the FileReader approach, the application will have to parse each progress event result object to determine meaningful chunks for the video decoder. Regards, Cyril [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#streamreader-interface [2] http://xhr.spec.whatwg.org/#the-responsetype-attribute [3] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On 12/14/12 6:49 AM, Jungkee Song wrote: FWIW, document.open() does not create a new Window object Yes, it does. See http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-open processing steps step 14. WebKit gets this wrong, but other UAs do it right. console.log(defaultDoc.defaultView.name); // InitWindow That's logging the navigation context name. console.log(document.defaultView.name); // InitWindow That's still logging the navigation context name. In particular, in the case above this: alert(XMLHttpRequest == window.XMLHttpRequest); alerts false per spec as far as I can tell, and the old Window is no longer associated with the document at this point. In the above example, as both of the two global objects refer to the same object, it results in true. Did you actually test this in a non-WebKit UA? The alert above alerts false in Gecko, as the spec requires it to. But note that you can get the same effect by just navigating the a browsing context, then calling a function that was defined in the no-longer-active document, without worrying about browsers that have buggy open() implementations. -Boris
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On Fri, Dec 14, 2012 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: But note that you can get the same effect by just navigating the a browsing context, then calling a function that was defined in the no-longer-active document, without worrying about browsers that have buggy open() implementations. The specification deals with that by having xhr.open() throw. I suppose the same would happen for the other case, since the associated Document object is no longer active. -- http://annevankesteren.nl/
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On 12/14/12 11:54 AM, Anne van Kesteren wrote: On Fri, Dec 14, 2012 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: But note that you can get the same effect by just navigating the a browsing context, then calling a function that was defined in the no-longer-active document, without worrying about browsers that have buggy open() implementations. The specification deals with that by having xhr.open() throw. Ah, indeed. OK. I suppose the same would happen for the other case, since the associated Document object is no longer active. Which other case? The document.open() one? In that case, there is no problem with the document per se; the only question is whether the XHR has an associated document object at all in that case... and per spec not having one does NOT cause open() to throw. -Boris
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On Fri, Dec 14, 2012 at 6:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: Which other case? The document.open() one? In that case, there is no problem with the document per se; the only question is whether the XHR has an associated document object at all in that case... and per spec not having one does NOT cause open() to throw. So you're saying that while there is an old Window object that the XMLHttpRequest interface object is on, it no longer has an associated Document object? I thought there was a 1:1 mapping. That would mean http://xhr.spec.whatwg.org/#dom-xmlhttprequest is bogus. If a Window object potentially has a Document object given this edge case I suppose what I would propose is that when it does not have one, XHR's document is set to null, and we throw for xhr.open(). -- http://annevankesteren.nl/
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On 12/14/12 12:54 PM, Anne van Kesteren wrote: On Fri, Dec 14, 2012 at 6:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: Which other case? The document.open() one? In that case, there is no problem with the document per se; the only question is whether the XHR has an associated document object at all in that case... and per spec not having one does NOT cause open() to throw. So you're saying that while there is an old Window object that the XMLHttpRequest interface object is on, it no longer has an associated Document object? Well, more precisely the Document that used to be associated with it is now associated with a different Window. Whether it's also still associated with the old window is not obvious from the specs at first glance... I thought there was a 1:1 mapping. There isn't, in some cases. document.open creates a new Window but keeps the same Document. Doing a same-origin pageload in a navigation context that was showing the initial about:blank creates a new Document but keeps the same Window. Insert obligatory quote about sense of logic and doors. ;) That would mean http://xhr.spec.whatwg.org/#dom-xmlhttprequest is bogus. If a Window object potentially has a Document object given this edge case I suppose what I would propose is that when it does not have one, XHR's document is set to null, and we throw for xhr.open(). It would actually be easier to throw from the constructor, from an implementation point of view... But we could make either one work, I guess. -Boris
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On 12/14/12 1:55 PM, Anne van Kesteren wrote: It seems to depend on whether or not the old Window object still has an associated document. If it still points to the active document the above would work. If it points nowhere the above cannot work Well. It depends on whether we want to use the old Window or the new one, for one thing What do UAs do right now? Until pretty recently, Gecko used the currently active Window in the browsing context, assuming it was same-origin with the Window the constructor came from. At this point we use the Window the constructor came from, but it's been causing some problems; hence this thread. -Boris
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On 12/14/12 2:29 PM, Anne van Kesteren wrote: Per Hixie the Document is associated with both the old and the new Window. Meaning that XMLHttpRequest will function normally even though XMLHttpRequest != window.XMLHttpRequest. I'm not sure it actually will; Olli had some concerns about event dispatch in the responseXML if it's tied to the old window, not the new one, for example. Not sure to what extent those are Gecko-implementation-specific. -Boris Note that in Gecko the old window is in fact unhooked from the document during open(), to prevent memory leaks; we _may_ be able to change that, but it's not clear.
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On 12/14/2012 09:46 PM, Boris Zbarsky wrote: On 12/14/12 2:29 PM, Anne van Kesteren wrote: Per Hixie the Document is associated with both the old and the new Window. Meaning that XMLHttpRequest will function normally even though XMLHttpRequest != window.XMLHttpRequest. I'm not sure it actually will; Olli had some concerns about event dispatch in the responseXML if it's tied to the old window, not the new one, That concern is Gecko implementation detail. for example. Not sure to what extent those are Gecko-implementation-specific. -Boris Note that in Gecko the old window is in fact unhooked from the document during open(), to prevent memory leaks; we _may_ be able to change that, but it's not clear.
Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document
On Fri, Dec 14, 2012 at 9:38 PM, Ian Hickson i...@hixie.ch wrote:
Windows themselves don't point anywhere. There's a variety of
relationships from Window objects to Document objects (and vice versa).
What's the precise text or script you're asking about?
http://xhr.spec.whatwg.org/#dom-xmlhttprequest is the specification.
It defines that XHR's document is set to the document associated with
the global object of XHR's interface object when the constructor is
invoked. A piece of code was given by bz:
window.onload = function() {
document.open()
var x = new XMLHttpRequest; // what document?
}
This document is later used by the open() method of XHR, which also
checks it's fully active and throws an exception otherwise.
--
http://annevankesteren.nl/
Re: CfC: publish WD of XHR; deadline November 29
On Mon, 03 Dec 2012 14:07:40 +0100, Ms2ger ms2...@gmail.com wrote: On 12/03/2012 01:44 PM, Charles McCathie Nevile wrote: Just a reminder: this group is a forum for discussion of technical specifications, and follows the existing W3C process. Discussion of what process *should* be is off topic here. I find it unfortunate that you try to cut off discussions relevant to technical issues with our specifications by calling them process discussions. And we the chairs find it unfortunate that you continue to bombard the working group with discussions of and objections based on process, simply because there are technical considerations to what the process of this organisation should be. This is a formal warning. The discussion is off topic, so please desist. From my understanding reasons for the practice include the following: - W3C aims to provide stable specifications that can be used as references which won't change. This is a general underpinning of its policy for specifications published as TR documents. Making a normative reference to an unstable document obviously defeats this purpose. The argument that TR documents are in some way more stable than other documents is simply fallacious. This has been discussed at length here and in other venues; By stable, we mean are formally published as a stable reference. The technical issues this brings up, as I said in this thread, are known. I won't go into it again. Thank you. In this working group, please apply the same approach to other discussions of W3C process. Furthermore, I should point out that referencing the TR draft of WebIDL would (if anybody tried to implement the TR spec and its TR references; nobody does, of course) lead to a specification that is not implementable. The WebIDL used in XHR is not valid according to the 19 April 2012 CR of WebIDL. [...] [chaals' example of currently unwritten requirements] I find this comparison, in particular, to be unhelpful and rather rude. I'm sorry. If you'd like to discuss this further, in an appropriate forum, I will endeavour to find a comparison more to your taste. Otherwise, please accept my apologies. Nobody is suggesting using expletives in specifications. The only parallel I can imagine with the current situation is that some people seem offended by the existence of the WHATWG, and for some reason want to make sure no W3C publication ever mentions it. This is a misrepresentation of the facts, unless you have special knowledge of some person's individual motivation. In particular, both the chairs and many others have repeatedly expressed that credit should be given where credit is due, and in particular that appropriate references to WHAT-WG documents on the same topic are the sort of thing that should be in the spec, because that kind of reference is expected of socially competent adults. This is a currently accepted consensus of the group, and I do not recall having seen any dissent. It is also an extension of the discussion, and an inappropriate ascription of motives to others. The question here is whether WHAT-WG documents are suitable as *normative references for W3C specifications*. I had hoped we had been able to come to a somewhat more mature relationship between this WG and the WHATWG after the recent discussions about attribution, but changes like this make me lose confidence in the goals of the W3C Team and the chairs of this WG on this matter. That is unfortunate. I maintain my technical objections to the publication. The chairs maintain that your objection is not technical. In any event, we draw your attention to the sentence [[[ Consensus is not a prerequisite for approval to publish; the Working Group MAY request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements. ]]] - http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd in section 7.4.1 of the process document. We note your objection, and resolve to publish the Working Draft. for the chairs Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Tue, 4 Dec 2012, Charles McCathie Nevile wrote: This is a formal warning. I do not support the chairs in this. I stand by Ms2ger. He has not acted inappropriately and his complaints are valid. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Tue, 04 Dec 2012 01:50:35 +0100, Ian Hickson i...@hixie.ch wrote: ... This is just plagiarism. Ian, this accusation against colleagues of yours working in good faith is offensive, and it is untrue. It is therefore inappropriate for this mailing list. I will repeat, since you may have missed it, what I said [1] in an earlier side-branch of this thread discussing how credit should be given to Anne for his work on this specification. The general principle is that we expect to give credit for contribution (but recognise that this is always an approximation). This is orthogonal to W3C's referencing policy for specifications. The process, and W3C's publication rules, are off-topic for this working group. If you want to discuss issues, please do so in the relevant forum. You are able to write to the Advisory Board, request Google's Advisory Committee representative to raise the issue. Anybody can participate directly in the W3Process Community Group[3]. [[[ In particular I note consensus that we don't want to misrepresent contribution to the work. I considered it obvious - it is how civil adults work and it is an accepted part of W3C process and practice. On Sat, 24 Nov 2012 00:34:02 +0400, Glenn Adams gl...@skynav.com wrote: Is Anne the *sole* author? As I understand it, Anne wrote the words of various specifications. In other words, the person whose artistic expression is reflected in the document. Although various bits of boilerplate are just pattern repetition. he also did a significant proportion of the testing, thinking, and developing the content at a conceptual level. But no, I believe other people did parts of this work, unless Anne simply ignored anything other people had already done, or we accept that by repeating other people's work he has produced original work, which runs against what I believe is a common definition. In particular, other people contributed information to Anne as members of the Webapps working group - with an understanding that the resulting documents would be published by that working group. To try and whitewash that out of history seems to be somewhere down the slippery slope of plagiarism. Nobody has suggested that the contributions of those beyond the working group should be ignored or misrepresented, the arguments have been about the precise editorial details of how that is done - what is generally called wordsmithing or bikeshedding (depending on whether it is us or them doing it). ]]] [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0574.html [2] http://www.w3.org/community/w3process/ I note that I have now raised the issue of pubrules with Philippe le Hegaret, and expect that the document will be clarified. Since W3C works by consensus of its stakeholders, this is unlikely to happen instantly, but I will continue to follow the issue. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
Just a reminder: this group is a forum for discussion of technical specifications, and follows the existing W3C process. Discussion of what process *should* be is off topic here. On Sun, 02 Dec 2012 12:07:20 +0100, Jungkee Song jungk...@gmail.com wrote: On Sun, Dec 2, 2012 at 11:07 AM, James Robinson jam...@google.com Sure there is if the W3C version is stale, as is the case here. I don't think it's a technical issue to discuss. Right. Although there are technical aspects to the discussion, it is a process issue. There should be corresponding publication rules. We could hassle W3C into updating pubrules so it is clear. I have take the action item. Art, Charles, Doug, Can you help clarifying which links we have to use? By longstanding practice W3C specifications point where possible to references where W3C provides change control, its own guarantee of permanence, and its patent policy. General practice is to point to stable documents in normative references (e.g. the latest /TR version of something), allowing informative references to more or less anything you think is interesting. Until people started playing politics to the point of trying to usurp change control through parallel references it seems nobody was terribly worried about this. The requirement isn't documented in pubrules last I looked, but by process W3C could change that with 10 minutes of work. I am not even sure that the rationale is clearly documented in any one place at the moment. Like the rest of W3C it has developed over a couple of decades. From my understanding reasons for the practice include the following: - W3C aims to provide stable specifications that can be used as references which won't change. This is a general underpinning of its policy for specifications published as TR documents. Making a normative reference to an unstable document obviously defeats this purpose. - Since 2005 W3C patent commitments are given by W3C participants to the work of W3C working groups. Unstable documents that from time to time have, or had, more or less equivalent content, are not a replacement for those who care about W3C's IPR policy - which includes people far beyond the scope of W3C's own membership. Although WHAT-WG is a Community Group, its living standard model has explicitly disavowed making a final specification. This seriously limits patent commitment even from its own members. - A couple of years ago, W3C was granted PAS submission status, after applying for this at the urging of many of its members and of non-member consumers of its specifications. This relies on lots of things, but one of them is a certain clarity of process. ISO accepted W3C's process. I don't know if they would be prepared to accept that of the WHAT-WG. I don't even know anyone who cares enough to find out. In the meantime, I suspect this is another reason not to make normative references to the WHAT-WG's work and in particular to unstable documents. In the proposed version, I've changed the links to the following specs: - [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest W3C TR doc. - [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the latest W3C TR doc. I think that was reasonable. If any of those documents don't carry a link to their W3C editors' drafts, it might be useful to also provide them as an *informative* reference. That commit replaced a link to http://xhr.spec.whatwg.org/, last updated roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/ which is dated January 17th and is missing an entire section (section 6). This change does not affect any links in the result doc, and in fact this proposed publication will reduce the gap. The proposed WD is aligned with the WHATWG version except: - Progress Events is not merged but staying as a separate spec. Seems reasonable. As I said in one-on-one conversation at TPAC (and maybe repeated for minutes - I forget), I would prefer not to merge these. If this is controversial we can raise an issue on it. - Streams API is deferred to next version. You mean next version of XHR, or next draft of this spec? Either way, I don't see that this should stop publication. - The last three commits (Nov 22) in WHATWG has not been incorporated yet. We're publishing a Working Draft. And we are happy to produce a stabilised version and work on a new one. We want better specs, but making perfection the enemy of getting a spec good enough to use is not a goal. It also replaced a link to http://fetch.spec.whatwg.org/# with http://www.w3.org/TR/cors/# which is similarly out of date by the better part of a year and lacking handling for some HTTP status codes. Every single reference updated in this commit changed the document to point to an out-of-date and less valuable resource. It seems that you, like the author of the commit message, mistakenly
Re: CfC: publish WD of XHR; deadline November 29
On 12/03/2012 01:44 PM, Charles McCathie Nevile wrote: Just a reminder: this group is a forum for discussion of technical specifications, and follows the existing W3C process. Discussion of what process *should* be is off topic here. I find it unfortunate that you try to cut off discussions relevant to technical issues with our specifications by calling them process discussions. From my understanding reasons for the practice include the following: - W3C aims to provide stable specifications that can be used as references which won't change. This is a general underpinning of its policy for specifications published as TR documents. Making a normative reference to an unstable document obviously defeats this purpose. The argument that TR documents are in some way more stable than other documents is simply fallacious. This has been discussed at length here and in other venues; I won't go into it again. Furthermore, I should point out that referencing the TR draft of WebIDL would (if anybody tried to implement the TR spec and its TR references; nobody does, of course) lead to a specification that is not implementable. The WebIDL used in XHR is not valid according to the 19 April 2012 CR of WebIDL. - A couple of years ago, W3C was granted PAS submission status, after applying for this at the urging of many of its members and of non-member consumers of its specifications. This relies on lots of things, but one of them is a certain clarity of process. ISO accepted W3C's process. I don't know if they would be prepared to accept that of the WHAT-WG. I don't even know anyone who cares enough to find out. In the meantime, I suspect this is another reason not to make normative references to the WHAT-WG's work and in particular to unstable documents. I do not see how this is relevant; I though the process was clear, and that it did not censor references to particular organizations. That's not in the W3C pub rules or a good idea. It isn't written there, although it has been applied for as long as I can remember (which stretches back to before pubrules was a document). I would love to hear examples of where such a rule was applied before the W3C started co-publishing WHATWG specifications; in particular, cases where the W3C publication was significantly out-of-date in comparison to the alternative. To the extent W3C thinks this should apply, they should indeed write it in there, since it has recently become contentious. As long as the rule doesn't exist, one can hardly expect editors to comply with it. If we expect editors to simply do as we did before, we'd be stuck with DOM2-style specifications; I think we all agree that would not be good for interoperability. Pubrules doesn't, as far as I know, prohibit f-bombs in specs. W3C working group members, including editors, are expected to be socially competent adults, which is a catch-all for what would otherwise be an endless set of statements like people who know not to use the 'f word' in a spec even without a written rule. (If I recall correctly this is in section 3.1 of the process document. It certainly isn't worth looking up). I find this comparison, in particular, to be unhelpful and rather rude. Nobody is suggesting using expletives in specifications. The only parallel I can imagine with the current situation is that some people seem offended by the existence of the WHATWG, and for some reason want to make sure no W3C publication ever mentions it. I had hoped we had been able to come to a somewhat more mature relationship between this WG and the WHATWG after the recent discussions about attribution, but changes like this make me lose confidence in the goals of the W3C Team and the chairs of this WG on this matter. I maintain my technical objections to the publication. HTH Ms2ger
Re: CfC: publish WD of XHR; deadline November 29
On Sat, 1 Dec 2012, Ms2ger wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 I agree. That change is offensive. It gives credit to dozens of people who have done basically nothing productive at all, for work that a few of us have spent years doing. I find the W3C's behaviour here to be increasingly out of control, as someone I spoke to recently put it. It's discourteous and uncivil. If the W3C wants to write their own specs then that's fine, but stop forking work done by other people who have no interest in working with the W3C at this time. This is just plagiarism. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Sun, Dec 2, 2012 at 11:07 AM, James Robinson jam...@google.com wrote: Sure there is if the W3C version is stale, as is the case here. I don't think it's a technical issue to discuss. There should be corresponding publication rules. Art, Charles, Doug, Can you help clarifying which links we have to use? In the proposed version, I've changed the links to the following specs: - [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest W3C TR doc. - [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the latest W3C TR doc. That commit replaced a link to http://xhr.spec.whatwg.org/, last updated roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/ which is dated January 17th and is missing an entire section (section 6). This change does not affect any links in the result doc, and in fact this proposed publication will reduce the gap. The proposed WD is aligned with the WHATWG version except: - Progress Events is not merged but staying as a separate spec. - Streams API is deferred to next version. - The last three commits (Nov 22) in WHATWG has not been incorporated yet. Jungkee It also replaced a link to http://fetch.spec.whatwg.org/# with http://www.w3.org/TR/cors/# which is similarly out of date by the better part of a year and lacking handling for some HTTP status codes. Every single reference updated in this commit changed the document to point to an out-of-date and less valuable resource. It seems that you, like the author of the commit message, mistakenly think it's a goal to replace all links to point to W3C resources even when they are strictly worse. That's not in the W3C pub rules or a good idea. - James
Re: CfC: publish WD of XHR; deadline November 29
On 12/02/2012 12:07 PM, Jungkee Song wrote: On Sun, Dec 2, 2012 at 11:07 AM, James Robinson jam...@google.com wrote: Sure there is if the W3C version is stale, as is the case here. I don't think it's a technical issue to discuss. There should be corresponding publication rules. Art, Charles, Doug, Can you help clarifying which links we have to use? In the proposed version, I've changed the links to the following specs: - [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest W3C TR doc. - [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the latest W3C TR doc. Please revert all those changes. Thank you Ms2ger
Re: CfC: publish WD of XHR; deadline November 29
On 12/1/12 3:34 PM, ext Ms2ger wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 For a couple of years now, if a spec proposed for publication in TR includes a normative reference that hahas published as a TR, PLH has insisted the reference needs to be a W3C document (TR or ED). (I'm pretty sure a small number of references to non W3C documents slipped through but I consider those mistakes.) I asked Jungkee to make the reference changes to the TR versions so thanks Jungkee for the patch. It would be OK with me if the references were changed to W3C EDs. Would that take care of your objection? -AB
Re: CfC: publish WD of XHR; deadline November 29
On 12/02/2012 01:38 PM, Arthur Barstow wrote: On 12/1/12 3:34 PM, ext Ms2ger wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 For a couple of years now, if a spec proposed for publication in TR includes a normative reference that hahas published as a TR, PLH has insisted the reference needs to be a W3C document (TR or ED). (I'm pretty sure a small number of references to non W3C documents slipped through but I consider those mistakes.) I asked Jungkee to make the reference changes to the TR versions so thanks Jungkee for the patch. It would be OK with me if the references were changed to W3C EDs. Would that take care of your objection? No. I'd love to hear from plh why he would not leave decisions like these to the WG. Ms2ger
Re: CfC: publish WD of XHR; deadline November 29
On 11/27/2012 02:16 PM, Arthur Barstow wrote: On 11/27/12 12:21 AM, ext Jungkee Song wrote: From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, November 27, 2012 3:05 AM I think the next step is for the XHR Editors to create a TR version using the WD template so that everyone can see exactly what is being proposed for publication as a TR. Please create that version as soon as you can so that this CfC can be based on that version (rather than the ED) and reply with the URL of the TR version. (Please use 6 December 2012 as the publication date.) We prepared a proposed TR version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html Thanks Jungkee. All - http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html is the document proposed for publication as a TR and thus is the basis for this CfC. I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 pushed with a misleading commit message. Thanks Ms2ger
Re: CfC: publish WD of XHR; deadline November 29
On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote: On 11/27/2012 02:16 PM, Arthur Barstow wrote: On 11/27/12 12:21 AM, ext Jungkee Song wrote: From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, November 27, 2012 3:05 AM I think the next step is for the XHR Editors to create a TR version using the WD template so that everyone can see exactly what is being proposed for publication as a TR. Please create that version as soon as you can so that this CfC can be based on that version (rather than the ED) and reply with the URL of the TR version. (Please use 6 December 2012 as the publication date.) We prepared a proposed TR version at: http://dvcs.w3.org/hg/xhr/raw-**file/tip/TR/Overview.htmlhttp://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html Thanks Jungkee. All - http://dvcs.w3.org/hg/xhr/**raw-file/tip/TR/Overview.htmlhttp://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html is the document proposed for publication as a TR and thus is the basis for this CfC. I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/**2341e31323a4http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 pushed with a misleading commit message. since you don't say what is misleading, and since commit messages are irrelevant for W3C process, this objection is immaterial
Re: CfC: publish WD of XHR; deadline November 29
On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 pushed with a misleading commit message. since you don't say what is misleading, and since commit messages are irrelevant for W3C process, this objection is immaterial Ms2ger objected to the change, not the commit message, so your objection to the objection is misplaced. However, the commit message isn't long, so it's not difficult to puzzle out what ey might be referring to. In this case, it's the implication that changing a bunch of normative references from WHATWG specs to W3C copies of the specs is somehow necessary according to pubrules. ~TJ
Re: CfC: publish WD of XHR; deadline November 29
On Sat, Dec 1, 2012 at 5:54 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 6:34 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 pushed with a misleading commit message. since you don't say what is misleading, and since commit messages are irrelevant for W3C process, this objection is immaterial Ms2ger objected to the change, not the commit message, so your objection to the objection is misplaced. However, the commit message isn't long, so it's not difficult to puzzle out what ey might be referring to. In this case, it's the implication that changing a bunch of normative references from WHATWG specs to W3C copies of the specs is somehow necessary according to pubrules. Then whomever ms2ger is should say so. In any case, there is no reason to reference a WHATWG document if there is a W3C counterpart. Sure there is if the W3C version is stale, as is the case here. That commit replaced a link to http://xhr.spec.whatwg.org/, last updated roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/ which is dated January 17th and is missing an entire section (section 6). It also replaced a link to http://fetch.spec.whatwg.org/# with http://www.w3.org/TR/cors/# which is similarly out of date by the better part of a year and lacking handling for some HTTP status codes. Every single reference updated in this commit changed the document to point to an out-of-date and less valuable resource. It seems that you, like the author of the commit message, mistakenly think it's a goal to replace all links to point to W3C resources even when they are strictly worse. That's not in the W3C pub rules or a good idea. - James
Re: CfC: publish WD of XHR; deadline November 29
On Sat, Dec 1, 2012 at 7:07 PM, James Robinson jam...@google.com wrote: On Sat, Dec 1, 2012 at 5:54 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 6:34 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 pushed with a misleading commit message. since you don't say what is misleading, and since commit messages are irrelevant for W3C process, this objection is immaterial Ms2ger objected to the change, not the commit message, so your objection to the objection is misplaced. However, the commit message isn't long, so it's not difficult to puzzle out what ey might be referring to. In this case, it's the implication that changing a bunch of normative references from WHATWG specs to W3C copies of the specs is somehow necessary according to pubrules. Then whomever ms2ger is should say so. In any case, there is no reason to reference a WHATWG document if there is a W3C counterpart. Sure there is if the W3C version is stale, as is the case here. That commit replaced a link to http://xhr.spec.whatwg.org/, last updated roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/which is dated January 17th and is missing an entire section (section 6). It also replaced a link to http://fetch.spec.whatwg.org/# with http://www.w3.org/TR/cors/# which is similarly out of date by the better part of a year and lacking handling for some HTTP status codes. Every single reference updated in this commit changed the document to point to an out-of-date and less valuable resource. It seems that you, like the author of the commit message, mistakenly think it's a goal to replace all links to point to W3C resources even when they are strictly worse. That's not in the W3C pub rules or a good idea. I didn't suggest this was demanded by pubrules, and indeed, I pointed out in a prior message that the pub rules do not dictate what documents or referenced. My position w.r.t WHATWG documents is that they should never be referenced by a W3C document unless there is no other option. Why do I say this? Because WHATWG documents are never final, at least according their principals. The W3C should not reference a document that is by definition never going to reach a final state, at least that is my opinion. Further, the W3C should not reference a document for which the IPR status is not sufficiently well defined, again this is my opinion. You or others may disagree. In the cases in point, someone needs to determine if the referenced documents will continue to move forward in the W3C, and if so, then they need to be updated according to the W3C Process rules. [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0501.html
Re: CfC: publish WD of XHR; deadline November 29
I need to clarify one point: I don't mind W3C docs making informative references to WHATWG docs. For example, I wouldn't mind a W3C doc making a normative reference to a snapshot of a WHATWG doc that has been republished in the W3C while making an informative reference to its living counterpart in the WHATWG. On Sat, Dec 1, 2012 at 7:40 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 7:07 PM, James Robinson jam...@google.com wrote: On Sat, Dec 1, 2012 at 5:54 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 6:34 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams gl...@skynav.com wrote: On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote: I object to this publication because of this change: http://dvcs.w3.org/hg/xhr/rev/2341e31323a4 pushed with a misleading commit message. since you don't say what is misleading, and since commit messages are irrelevant for W3C process, this objection is immaterial Ms2ger objected to the change, not the commit message, so your objection to the objection is misplaced. However, the commit message isn't long, so it's not difficult to puzzle out what ey might be referring to. In this case, it's the implication that changing a bunch of normative references from WHATWG specs to W3C copies of the specs is somehow necessary according to pubrules. Then whomever ms2ger is should say so. In any case, there is no reason to reference a WHATWG document if there is a W3C counterpart. Sure there is if the W3C version is stale, as is the case here. That commit replaced a link to http://xhr.spec.whatwg.org/, last updated roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/which is dated January 17th and is missing an entire section (section 6). It also replaced a link to http://fetch.spec.whatwg.org/# with http://www.w3.org/TR/cors/# which is similarly out of date by the better part of a year and lacking handling for some HTTP status codes. Every single reference updated in this commit changed the document to point to an out-of-date and less valuable resource. It seems that you, like the author of the commit message, mistakenly think it's a goal to replace all links to point to W3C resources even when they are strictly worse. That's not in the W3C pub rules or a good idea. I didn't suggest this was demanded by pubrules, and indeed, I pointed out in a prior message that the pub rules do not dictate what documents or referenced. My position w.r.t WHATWG documents is that they should never be referenced by a W3C document unless there is no other option. Why do I say this? Because WHATWG documents are never final, at least according their principals. The W3C should not reference a document that is by definition never going to reach a final state, at least that is my opinion. Further, the W3C should not reference a document for which the IPR status is not sufficiently well defined, again this is my opinion. You or others may disagree. In the cases in point, someone needs to determine if the referenced documents will continue to move forward in the W3C, and if so, then they need to be updated according to the W3C Process rules. [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0501.html
Re: CfC: publish WD of XHR; deadline November 29
On 11/27/12 12:21 AM, ext Jungkee Song wrote: From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, November 27, 2012 3:05 AM I think the next step is for the XHR Editors to create a TR version using the WD template so that everyone can see exactly what is being proposed for publication as a TR. Please create that version as soon as you can so that this CfC can be based on that version (rather than the ED) and reply with the URL of the TR version. (Please use 6 December 2012 as the publication date.) We prepared a proposed TR version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html Thanks Jungkee. All - http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html is the document proposed for publication as a TR and thus is the basis for this CfC. -Thanks, AB
Re: CfC: publish WD of XHR; deadline November 29
On 11/26/12 1:38 AM, ext Jungkee Song wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. Please put your proposed text in a version of the spec we can review and send us the URL of that version. -Thanks, AB
Re: CfC: publish WD of XHR; deadline November 29
On Mon, Nov 26, 2012 at 4:05 AM, Ian Hickson i...@hixie.ch wrote: I don't know what official would mean here. I just meant the intent that is behind my (and Anne's, I believe) advocacy of open licensing for specifications. Yup. -- http://annevankesteren.nl/
Re: [admin] XHR ED Boilerplate
I agree with Ian's other observations/comments. On Fri, Nov 23, 2012 at 10:22 PM, Ian Hickson i...@hixie.ch wrote: What I don't really understand, though, is why any of this is needed at all. What value is the W3C adding by creating these forks? In the end (dunno when that will be), patent commitments from the Members of the WebApps WG. That seems worthwhile to me. It is unfortunate I could not reach an agreement with the W3C where I could publish my work under CC0 and still achieve that. -- http://annevankesteren.nl/
RE: CfC: publish WD of XHR; deadline November 29
From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 26, 2012 9:46 PM On 11/26/12 1:38 AM, ext Jungkee Song wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. Please put your proposed text in a version of the spec we can review and send us the URL of that version. Please find the version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Jungkee
Re: CfC: publish WD of XHR; deadline November 29
On 11/26/2012 02:44 PM, Jungkee Song wrote: From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 26, 2012 9:46 PM On 11/26/12 1:38 AM, ext Jungkee Song wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. Please put your proposed text in a version of the spec we can review and send us the URL of that version. Please find the version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Thanks, this looks a lot better. However, I'd also like to see a link to the source in the dl in the header. Thanks Ms2ger
Re: [admin] XHR ED Boilerplate
(12/11/26 21:25), Anne van Kesteren wrote: I agree with Ian's other observations/comments. I suppose that doesn't include (12/11/24 5:22), Ian Hickson wrote: Also, the document asks for feedback on the public-webapps list, but that fragments feedback on the spec; the WHATWG copy instead suggests feedback go to the WHATWG list. ? Currently, http://xhr.spec.whatwg.org/ has # Participate: # Send feedback to public-webapps@w3.org (archives) or file a bug # (open bugs) File a bug about the selected text # IRC: #whatwg on Freenode . And the WHATWG list is in the list of archives of historical discussions. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [admin] XHR ED Boilerplate
On Mon, Nov 26, 2012 at 3:11 PM, Kang-Hao (Kenny) Lu kangh...@oupeng.com wrote: (12/11/24 5:22), Ian Hickson wrote: Also, the document asks for feedback on the public-webapps list, but that fragments feedback on the spec; the WHATWG copy instead suggests feedback go to the WHATWG list. ? Currently, http://xhr.spec.whatwg.org/ has Ian was talking about the URL Standard. -- http://annevankesteren.nl/
Re: [admin] XHR ED Boilerplate
(12/11/26 22:11), Kang-Hao (Kenny) Lu wrote: (12/11/26 21:25), Anne van Kesteren wrote: I agree with Ian's other observations/comments. I suppose that doesn't include (12/11/24 5:22), Ian Hickson wrote: Also, the document asks for feedback on the public-webapps list, but that fragments feedback on the spec; the WHATWG copy instead suggests feedback go to the WHATWG list. ? Currently, http://xhr.spec.whatwg.org/ has Nevermind. That was referring to http://url.spec.whatwg.org/. I guess doing this differently is indeed a bit confusing. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: CfC: publish WD of XHR; deadline November 29
On 11/26/12 8:44 AM, ext Jungkee Song wrote: From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 26, 2012 9:46 PM On 11/26/12 1:38 AM, ext Jungkee Song wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. Please put your proposed text in a version of the spec we can review and send us the URL of that version. Please find the version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Thanks Jungkee. I think the next step is for the XHR Editors to create a TR version using the WD template so that everyone can see exactly what is being proposed for publication as a TR. Please create that version as soon as you can so that this CfC can be based on that version (rather than the ED) and reply with the URL of the TR version. (Please use 6 December 2012 as the publication date.) -Thanks, AB
Re: [admin] XHR ED Boilerplate
On Mon, 26 Nov 2012, Anne van Kesteren wrote: I agree with Ian's other observations/comments. On Fri, Nov 23, 2012 at 10:22 PM, Ian Hickson i...@hixie.ch wrote: What I don't really understand, though, is why any of this is needed at all. What value is the W3C adding by creating these forks? In the end (dunno when that will be), patent commitments from the Members of the WebApps WG. That seems worthwhile to me. It is unfortunate I could not reach an agreement with the W3C where I could publish my work under CC0 and still achieve that. I'm all in favour of that, but if that's the goal, there's no point the WG doing anything until there's something that could actually go to REC, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Mon, Nov 26, 2012 at 5:53 AM, Ms2ger ms2...@gmail.com wrote: On 11/26/2012 02:44 PM, Jungkee Song wrote: From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 26, 2012 9:46 PM On 11/26/12 1:38 AM, ext Jungkee Song wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. Please put your proposed text in a version of the spec we can review and send us the URL of that version. Please find the version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Thanks, this looks a lot better. Yes. Thanks for addressing my concern. Adam However, I'd also like to see a link to the source in the dl in the header. Thanks Ms2ger
RE: CfC: publish WD of XHR; deadline November 29
From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, November 27, 2012 3:05 AM I think the next step is for the XHR Editors to create a TR version using the WD template so that everyone can see exactly what is being proposed for publication as a TR. Please create that version as soon as you can so that this CfC can be based on that version (rather than the ED) and reply with the URL of the TR version. (Please use 6 December 2012 as the publication date.) We prepared a proposed TR version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html Thank you. Jungkee -Thanks, AB
Re: CfC: publish WD of XHR; deadline November 29
Le 22/11/2012 18:16, Ms2ger a écrit : On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I'm unfamiliar with the W3C process, so sorry if my question is stupid, but why would it be necessary? (I assume you're talking about http://xhr.spec.whatwg.org/) Quoting http://xhr.spec.whatwg.org/ Editor: Anne van Kesteren ann...@annevk.nl CC0 To the extent possible under law, the editor has waived all copyright and related or neighboring rights to this work. In addition, as of 22 November 2012, the editor has made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Quoting http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0 (emphasis is mine) 2.1. Copyright Grant. I grant to you a perpetual (for the duration of the applicable copyright), worldwide, non-exclusive, no-charge, royalty-free, copyright license, *without any obligation for accounting to me*, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, distribute, and implement the Specification to the full extent of my copyright interest in the Specification. This wording makes pretty clear that pointing to the whatwg spec isn't required or necessary or anything. It would be pretty hypocritical to put some work under CC0/public domain/OWFAV1.0 and expect or even demand to be credited. Some licences (CC-BY as an example) require crediting the original author. I assume a purposeful choice has been made by Anne and the WHATWG to put the work under a licence that doesn't have such a requirement. Choosing a licence applied to some work shows an intention of how one expects the work to be reused. The intention here is pretty clear and says I don't care of being credited. Choosing a licence is a serious choice with serious implications. If the WHATWG expects credit, maybe it should consider re-licence its work (which would be easy given the current licence ;-) ) to a licence expressing more clearly this intent instead of expecting others to guess the intent and throwing accusations of plagiarism. David
Re: [admin] XHR ED Boilerplate
Warning. This discussion seems by and large non-technical bike-shedding for political purposes, which I have tried to stay away from. But some important points are drowning in rhetorical over the several threads that have dealt with this "issue".In particular I note consensus that we don't want to misrepresent contribution to the work. I considered it obvious - it is how civil adults work and it is an accepted part of W3C process and practice.On Sat, 24 Nov 2012 00:34:02 +0400, Glenn Adams gl...@skynav.com wrote:Is Anne the *sole* author?As I understand it, Anne wrote the words of various specifications. In other words, the person whose "artistic _expression_" is reflected in the document. Although various bits of boilerplate are just pattern repetition. he also did a significant proportion of the testing, thinking, and developing the content at a conceptual level.But no, I believe other people did parts of this work, unless Anne simply ignored anything other people had already done, or we accept that by repeating other people's work he has produced original work, which runs against what I believe is a common definition.In particular, other people contributed information to Anne as members of the Webapps working group - with an understanding that the resulting documents would be published by that working group. To try and whitewash that out of history seems to be somewhere down the slippery slope of plagiarism.Nobody has suggested that the contributions of those beyond the working group should be ignored or misrepresented, the arguments have been about the precise editorial details of how that is done - what is generally called "wordsmithing" or "bikeshedding" (depending on whether it is "us" or "them" doing it).I don't think "author" is a particularly accurate description, but I don't think that what people who contribute are called by the specification is a particularly important issue, so long as it is roughly accurate. So far I am happy enough with how the different people who have done the work of preparing different documents choose to represent the different contributions made. If it's good enough for the "I can live with it" test in a world where we don't want to minutely examine every person's work, but would rather focus on actually making progress I am happy to live with the varying details, in order to keep working in such a world.I suggest that is a more productive way for the Working Group to continue, and more respectful of people who have done significant hard work in the expectation that it would benefit the stakeholders in the web, rather than any individual or group's perceived place in history.cheersChaalsDid the WG or others not contribute any text or suggested text to the spec? It seems like a bit of a slippery slope to attempt to designate a sole author for any W3C product. You might want to check with the pubs team on this matter. On Fri, Nov 23, 2012 at 11:44 AM, Arthur Barstow art.bars...@nokia.com wrote: [ Sorry for the delayed response, I was choking on some turkey ... ] Here's what I did for the URL spec re the boilerplate to help address the "attribution issue" re Anne and WHATWG: [[ http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html This Version: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html Latest WHATWG Version: http://url.spec.whatwg.org/ Previous Versions: http://www.w3.org/TR/2012/ED-url-20120524/ Author: Anne van Kesteren ann...@annevk.nl Editor: Web Applications Working Group public-webapps@w3.org Former editors: Adam Barth w...@adambarth.com Erik Arvidsson a...@chromium.org Michael[tm] Smith m...@w3.org ]] In the case of XHR, the new Editors would be listed as Editors and if they made contributions to the spec, they would also be added to the Author list too. If something like that would not be acceptable for the XHR ED, what specific change(s) do you request? -Thanks, AB -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Sun, Nov 25, 2012 at 10:34 AM, David Bruant bruan...@gmail.com wrote: Le 22/11/2012 18:16, Ms2ger a écrit : On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/**raw-file/tip/Overview.htmlhttp://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html . Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I'm unfamiliar with the W3C process, so sorry if my question is stupid, but why would it be necessary? (I assume you're talking about http://xhr.spec.whatwg.org/) Quoting http://xhr.spec.whatwg.org/ Editor: Anne van Kesteren ann...@annevk.nl CC0 To the extent possible under law, the editor has waived all copyright and related or neighboring rights to this work. In addition, as of 22 November 2012, the editor has made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.**org/legal/the-owf-1-0-**agreements/owfa-1-0http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Quoting http://www.openwebfoundation.**org/legal/the-owf-1-0-** agreements/owfa-1-0http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0(emphasis is mine) 2.1. Copyright Grant. I grant to you a perpetual (for the duration of the applicable copyright), worldwide, non-exclusive, no-charge, royalty-free, copyright license, *without any obligation for accounting to me*, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, distribute, and implement the Specification to the full extent of my copyright interest in the Specification. This wording makes pretty clear that pointing to the whatwg spec isn't required or necessary or anything. It would be pretty hypocritical to put some work under CC0/public domain/OWFAV1.0 and expect or even demand to be credited. Some licences (CC-BY as an example) require crediting the original author. I assume a purposeful choice has been made by Anne and the WHATWG to put the work under a licence that doesn't have such a requirement. Choosing a licence applied to some work shows an intention of how one expects the work to be reused. The intention here is pretty clear and says I don't care of being credited. Choosing a licence is a serious choice with serious implications. If the WHATWG expects credit, maybe it should consider re-licence its work (which would be easy given the current licence ;-) ) to a licence expressing more clearly this intent instead of expecting others to guess the intent and throwing accusations of plagiarism. David Have you read Adam Barth's contributions to this discussion? He has summarized the point well, I think. There is a difference between what the license legally obligates one to do and what professionals working in good faith towards similar goals do. - Kyle
Re: CfC: publish WD of XHR; deadline November 29
On Sun, 25 Nov 2012 22:34:03 +0400, David Bruant bruan...@gmail.com wrote: Le 22/11/2012 18:16, Ms2ger a écrit : On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I'm unfamiliar with the W3C process, so sorry if my question is stupid, but why would it be necessary? It isn't, for the reasons you point out. But it is good manners to make some reasonable acknowledgement of contribution, and therefore considered a requirement in practice. (I'm unconvinced that this group's time should be spent on the finer nuances of exactly what that text should be and where it should go, but that an acknowledgement is required I consider settled question). cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
Le 25/11/2012 20:07, Kyle Huey a écrit : Have you read Adam Barth's contributions to this discussion? Sure, and I personally mostly agree with these points. He has summarized the point well, I think. There is a difference between what the license legally obligates one to do I talked very briefly in terms of legally and spent more time talking about author intent on purpose. As I said, licences have a legal part to them, but also (and mostly?) convey an intent. Actually, Anne made extremely clear what he meant in a recent post [1]: Most of the WHATWG documents are published in the public domain (CC0 for countries that do not recognize the public domain). I think this is important because these are documents that define part of the architecture of the web. Nobody and no organization should be entitled to them. The intent is clear: the WHATWG publishes documents in the public domain for very good reason. Anyone (W3C included!) can reuse them under close to no condition, not even credit. and what professionals working in good faith towards similar goals do. Now, after discussing the author intention, we can discuss what professionals working in good faith do, but we're starting to get in a blurry field where people from different cultures will have very different definitions of what professional, work and good faith mean. Adam Barth has his definition (which I agree with, by the way). It appears from the latest messages on this thread that the W3C agrees with his definition so everything is fine. In case the W3C didn't agree (which it was initially accused of), maybe adding the WHATWG definition of what professionals working in good faith do to its licence (as a show of intention, the legal part would just be a side effect) could clear up cross-cultural ambiguities and remove a good share of conflicts. Once again, publishing work under public domain and expecting others to respect mystical things like what professionals working in good faith do is hypocritical. If you expect someone else to behave is some way, the first step is expressing your expectations (the licence being one clear way to do so), not expecting others to guess! Especially not on the web where people from so many different cultures meet! Clearly communicating intent and expectations is something I'd expect from professionals working in good faith. I'm glad it happened in this thread, I'm sad it took conflicts and tensions. David Ps : The importance of the intention behind a licence (besides the purely legal aspect) can be seen elsewhere as the example of the AGPL Licence and the Neo4J interpretation shows: http://stackoverflow.com/questions/6500925/agpl-license-question-re-neo4j [1] http://annevankesteren.nl/2012/11/copyright
Re: CfC: publish WD of XHR; deadline November 29
On Sun, 25 Nov 2012, David Bruant wrote: The intent is clear: the WHATWG publishes documents in the public domain for very good reason. Anyone (W3C included!) can reuse them under close to no condition, not even credit. I can speak pretty authoritatively to the intent, if that's what you are interested in. The relevant philosophy in the WHATWG context is multi-pronged: 1: Specs should be reusable in software, documentation, tutorials, and the like, without any barrier, whether free software or proprietary software, whether in books printed for money or FAQs that are themselves free to copy, whether in online courses with $10,000 entry fees or demos on street corners that are organised by marketing departments. 2: A spec author can go bad without realising it, so it should be possible to fork a specification if that happens, without the author having any control over this. 3: Forking specifications, publishing multiple copies of specifications, and publishing easy-to-find-with-a-search-engine snapshots of specifications, are all things that hurt interoperability by making implementors reference different requirements. The only time that forking a specification is justified is #2 above. We use open licenses on our specifications because of #1 and #2. We can't legally prevent #3 while allowing #1 and #2, so we rely on common sense and good faith to achieve #3. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: publish WD of XHR; deadline November 29
On Sun, Nov 25, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 25 Nov 2012, David Bruant wrote: The intent is clear: the WHATWG publishes documents in the public domain for very good reason. Anyone (W3C included!) can reuse them under close to no condition, not even credit. I can speak pretty authoritatively to the intent, if that's what you are interested in. The relevant philosophy in the WHATWG context is multi-pronged: 1: Specs should be reusable in software, documentation, tutorials, and the like, without any barrier, whether free software or proprietary software, whether in books printed for money or FAQs that are themselves free to copy, whether in online courses with $10,000 entry fees or demos on street corners that are organised by marketing departments. 2: A spec author can go bad without realising it, so it should be possible to fork a specification if that happens, without the author having any control over this. 3: Forking specifications, publishing multiple copies of specifications, and publishing easy-to-find-with-a-search-engine snapshots of specifications, are all things that hurt interoperability by making implementors reference different requirements. The only time that forking a specification is justified is #2 above. We use open licenses on our specifications because of #1 and #2. We can't legally prevent #3 while allowing #1 and #2, so we rely on common sense and good faith to achieve #3. I'm not sure in what capacity you are writing this. However I'll note that not everyone at least at Mozilla agree with #3. I forget exactly what policies govern WHATWG, but I don't know if the above can be considered an official WHATWG policy. / Jonas
Re: CfC: publish WD of XHR; deadline November 29
On Sun, 25 Nov 2012, Jonas Sicking wrote: On Sun, Nov 25, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 25 Nov 2012, David Bruant wrote: The intent is clear: the WHATWG publishes documents in the public domain for very good reason. Anyone (W3C included!) can reuse them under close to no condition, not even credit. I can speak pretty authoritatively to the intent, if that's what you are interested in. The relevant philosophy in the WHATWG context is multi-pronged: 1: Specs should be reusable in software, documentation, tutorials, and the like, without any barrier, whether free software or proprietary software, whether in books printed for money or FAQs that are themselves free to copy, whether in online courses with $10,000 entry fees or demos on street corners that are organised by marketing departments. 2: A spec author can go bad without realising it, so it should be possible to fork a specification if that happens, without the author having any control over this. 3: Forking specifications, publishing multiple copies of specifications, and publishing easy-to-find-with-a-search-engine snapshots of specifications, are all things that hurt interoperability by making implementors reference different requirements. The only time that forking a specification is justified is #2 above. We use open licenses on our specifications because of #1 and #2. We can't legally prevent #3 while allowing #1 and #2, so we rely on common sense and good faith to achieve #3. I'm not sure in what capacity you are writing this. [...] I forget exactly what policies govern WHATWG, but I don't know if the above can be considered an official WHATWG policy. I don't know what official would mean here. I just meant the intent that is behind my (and Anne's, I believe) advocacy of open licensing for specifications. However I'll note that not everyone at least at Mozilla agree with #3. #3 is actually the most empirically testable one, at least the first sentence of it. Given the number of e-mails I get from implementors asking me questions with links to outdated snapshots of specs they found via search engines, where their question was already answered by the editor's draft of that spec, I don't really see how it can be controversial. :-) What do you think justifies having multiple copies of a spec? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: CfC: publish WD of XHR; deadline November 29
Hi, I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. As the co-Editors of W3C XHR spec wrote in the threads, we have our role and contribution in moving this spec toward the W3C REC. Up to the moment, we mostly had to take care of the gaps between W3C version and WHATWG version to make them convergent. We will try to make more productive discussions along the way from this point on. [Status of this Document] This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. If you wish to make comments regarding this document in a manner that is tracked by the W3C, please submit them via using our public bug database ( https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG), or please send comments to public-webapps@w3.org (archived) with [XHR] at the start of the subject line. The bulk of the text of this specification is also available in the WHATWG *XMLHttpRequest Living Standard (link to the whatwg spec)*, under a license that permits reuse of the specification text. *The W3C Web Applications Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track.* This specification is the 22 November 2012 Editor's Draft. Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. *Work on this specification is also done at the WHATWG. The W3C Web Applications working group actively pursues convergence of XMLHttpRequest specification with the WHATWG.* This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. This document supersedes XMLHttpRequest 1. [Acknowledgments] +Special thanks to Anne van Kesteren who has provided nearly all the contents until he stepped down as a W3C editor and is now in succession providing discussions and contents as the editor of the XMLHttpRequest Living Standard in WHATWG which this version of the specification pursues convergence. Jungkee -Original Message- From: Kang-Hao (Kenny) Lu [mailto:kangh...@oupeng.com] Sent: Saturday, November 24, 2012 2:44 AM To: WebApps WG Subject: Re: CfC: publish WD of XHR; deadline November 29 (12/11/24 1:28), Adam Barth wrote: Now, that being said and seeing as we cannot put Anne as an editor of the W3C version of the spec (because, technically, he's not). How do you guys suggest we go about acknowledging the WHATWG source? Where in the spec? How? With what kind of wording? I would recommend acknowledging the WHATWG upfront in the Status of this Document. The document currently reads: ---8--- This document is produced by the Web Applications (WebApps) Working Group. The WebApps Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain. ---8--- Just in case folks don't know. HTML5 also has a paragraph like this in the Status of this Document: # The bulk of the text of this specification is also available in the # WHATWG HTML Living Standard, under a license that permits reuse of # the specification text. Another possibility is to say something like | Anne van Kesteran authored most of the text in the spec. in the Acknowledgment section. I'd note that in CSS specs an Acknowledgment section is not always just a list of names and so suppose this is doable. I'm not pushing for this though, as I find this quite obvious. Perhaps Anne would be willing to suggest some text that he would find appropriate? +1, or perhaps Anne would like to object to this CfC no matter what? Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: CfC: publish WD of XHR; deadline November 29
On Mon, 26 Nov 2012 10:38:35 +0400, Jungkee Song jungkee.s...@samsung.com wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. The proposed wording seems accurate enough to meet my I can live with it test. As the co-Editors of W3C XHR spec wrote in the threads, we have our role and contribution in moving this spec toward the W3C REC. Up to the moment, we mostly had to take care of the gaps between W3C version and WHATWG version to make them convergent. We will try to make more productive discussions along the way from this point on. Indeed. Thank you chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Thu, Nov 22, 2012 at 6:27 AM, Anne van Kesteren ann...@annevk.nl wrote: If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Putting my name as former editor while all the text is either written by me or copied from me seems disingenuous. note that the label editor does not imply authorship; authors of W3C specs do not necessarily correspond to editors; in other cases in the W3C where editors change over the document's lifetime, all of the editors are often listed without marking which are current and which are not current; perhaps that would serve here, i.e., just include Anne in the list of editors
Re: CfC: publish WD of XHR; deadline November 29
On Fri, Nov 23, 2012 at 12:09 AM, Adam Barth w...@adambarth.com wrote: On Thu, Nov 22, 2012 at 9:16 AM, Ms2ger ms2...@gmail.com wrote: On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I agree. The W3C should not be in the business of plagiarizing the work of others. Are you claiming that the W3C is in the business of plagiarizing? plagiarism. n. The practice of taking someone else's work or ideas and passing them off as one's own. The Status of this Document section should state clearly that this document is not an original work of authorship of the W3C. The SotD section need only refer to the working group that produced the document. Authorship is not noted or tracked in W3C documents. If Anne's work was submitted to and prepared in the context of the WebApps WG, then it is a product of the WG, and there is no obligation to refer to other, prior or variant versions. Referring to an earlier, draft version published outside of the W3C process does not serve any purpose nor is it required by the W3C Process. If there is a question on the status of the Copyright declaration of the material or its origin, then that should be taken up by the W3C Pubs team. G.
Re: CfC: publish WD of XHR; deadline November 29
On Fri, Nov 23, 2012 at 4:57 PM, Glenn Adams gl...@skynav.com wrote: If Anne's work was submitted to and prepared in the context of the WebApps WG, then it is a product of the WG, and there is no obligation to refer to other, prior or variant versions. To be clear, in http://dvcs.w3.org/hg/xhr/shortlog Merge Anne's change is referring to edits I made to http://xhr.spec.whatwg.org/ and have then been copied over. -- http://annevankesteren.nl/
Re: CfC: publish WD of XHR; deadline November 29
On Fri, Nov 23, 2012 at 7:57 AM, Glenn Adams gl...@skynav.com wrote: On Fri, Nov 23, 2012 at 12:09 AM, Adam Barth w...@adambarth.com wrote: On Thu, Nov 22, 2012 at 9:16 AM, Ms2ger ms2...@gmail.com wrote: On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I agree. The W3C should not be in the business of plagiarizing the work of others. Are you claiming that the W3C is in the business of plagiarizing? I'm saying that the W3C (and this working group in particular) is taking Anne's work, without his permission, and passing it off as its own. That is plagiarism, and we should not do it. plagiarism. n. The practice of taking someone else's work or ideas and passing them off as one's own. The Status of this Document section should state clearly that this document is not an original work of authorship of the W3C. The SotD section need only refer to the working group that produced the document. Authorship is not noted or tracked in W3C documents. If Anne's work was submitted to and prepared in the context of the WebApps WG, then it is a product of the WG, and there is no obligation to refer to other, prior or variant versions. Referring to an earlier, draft version published outside of the W3C process does not serve any purpose nor is it required by the W3C Process. Legally, we are under no obligation to acknowledge Anne's work. However, we should be honest about the origin of the text and not try to pass off Anne's work as our own. More pointedly: plagiarism is not illegal but that doesn't mean we should do it. If there is a question on the status of the Copyright declaration of the material or its origin, then that should be taken up by the W3C Pubs team. My concern is not about copyright. My concern is about passing off Anne's work as our own. Adam
Re: Re: CfC: publish WD of XHR; deadline November 29
Are you claiming that the W3C is in the business of plagiarizing? I'm saying that the W3C (and this working group in particular) is taking Anne's work, without his permission, and passing it off as its own. Speaking as one of the W3C-editors of the spec: first I agree that crediting needs to be sorted out, and that Anne should be credited in a way that better reflects his contributions. I appreciate that Ms2ger points this out during the RfC. Secondly, I think it's a bit harsh to say that we take his work without his permission - legally I believe the WHATWG deliberately publishes under a licence that allows this, and on a moral and practical basis as W3C-editors intend to collaborate with Anne in the best possible way under a situation that's not really by our design, we involve him in discussions, appreciate his input, I've also sent pull requests on GitHub to keep the specs in sync and intend to continue to do so. I hope that claiming that we act without Anne's permission depicts a working environment that's less constructive than what we're both aiming for and achieving. -- Hallvord R. M. Steen Core tester, Opera Software
Re: CfC: publish WD of XHR; deadline November 29
On 11/23/12 5:36 PM, Adam Barth w...@adambarth.com wrote: However, we should be honest about the origin of the text and not try to pass off Anne's work as our own. Or better yet, provide a canvas where Anne is able to do his work as part of the WebApps WG. --tobie
Re: Re: CfC: publish WD of XHR; deadline November 29
On Fri, Nov 23, 2012 at 9:01 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Are you claiming that the W3C is in the business of plagiarizing? I'm saying that the W3C (and this working group in particular) is taking Anne's work, without his permission, and passing it off as its own. Speaking as one of the W3C-editors of the spec: first I agree that crediting needs to be sorted out, and that Anne should be credited in a way that better reflects his contributions. I appreciate that Ms2ger points this out during the RfC. Secondly, I think it's a bit harsh to say that we take his work without his permission - legally I believe the WHATWG deliberately publishes under a licence that allows this, and on a moral and practical basis as W3C-editors intend to collaborate with Anne in the best possible way under a situation that's not really by our design, we involve him in discussions, appreciate his input, I've also sent pull requests on GitHub to keep the specs in sync and intend to continue to do so. I hope that claiming that we act without Anne's permission depicts a working environment that's less constructive than what we're both aiming for and achieving. I'm happy that you and Anne have a productive working relationship. My comment is based on this message: http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0538.html Perhaps I should have moved the phrase without his permission to the end of the sentence. Adam
Re: CfC: publish WD of XHR; deadline November 29
On Fri, Nov 23, 2012 at 9:36 AM, Adam Barth w...@adambarth.com wrote: My concern is not about copyright. My concern is about passing off Anne's work as our own. As I have pointed out above, W3C specs do not track authorship or individual contributions to the WG process. If Anne performed his work as author in the context of participating in the W3C process, then there is no obligation to acknowledge that, though there is a long standing practice of including an Acknowledgments section or paragraph that enumerates contributors. I would think that listing Anne as Editor or Former Editor and listing Anne in an Acknowledgments paragraph should be entirely consistent with all existing W3C practice. Are you asking for more than this? And if so, then what is the basis for that?
Re: CfC: publish WD of XHR; deadline November 29
Hi all, In an ideal world, Anne would be the editor of the W3C version of the spec and that would be the end of it. Such is not the case. Anne is not the editor of the W3C version: he doesn't edit and/or publish anything related to the W3C XHR spec. Current editors do and while it's mostly brain-dead copy/paste, some decisions (especially regarding spec merging) are to be made W3C-side. Current editors also act as first-level reviewers and actually give Anne feedback. To be honest, I hate this situation. As far as I'm concerned, Anne *is* the author of the XHR spec but, AFAIK, there is no standardized way to acknowledge this in W3C documents nor does the WHATWG Licensing makes it mandatory. As a side note, as an open source developper, I can understand why. If the specs are on public repos and accept pull requests (or diffs, or whatever), then the very notion of authorship becomes a bit blurry. Anyway, I'm one of the co-editor of the W3C XHR spec and I don't claim to be the author of anything in the spec. I'm more interested in pushing the spec forward than achieving glory. I accepted the co-editor position to help because help was needed. So while I empathize with the whole W3C plagiarizes WHATWG outrage, could this conversation be held where it belongs? That is far upper the food chain than this WG. Now, that being said and seeing as we cannot put Anne as an editor of the W3C version of the spec (because, technically, he's not). How do you guys suggest we go about acknowledging the WHATWG source? Where in the spec? How? With what kind of wording? -- Julian Aubourg On 23 November 2012 17:36, Adam Barth w...@adambarth.com wrote: On Fri, Nov 23, 2012 at 7:57 AM, Glenn Adams gl...@skynav.com wrote: On Fri, Nov 23, 2012 at 12:09 AM, Adam Barth w...@adambarth.com wrote: On Thu, Nov 22, 2012 at 9:16 AM, Ms2ger ms2...@gmail.com wrote: On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I agree. The W3C should not be in the business of plagiarizing the work of others. Are you claiming that the W3C is in the business of plagiarizing? I'm saying that the W3C (and this working group in particular) is taking Anne's work, without his permission, and passing it off as its own. That is plagiarism, and we should not do it. plagiarism. n. The practice of taking someone else's work or ideas and passing them off as one's own. The Status of this Document section should state clearly that this document is not an original work of authorship of the W3C. The SotD section need only refer to the working group that produced the document. Authorship is not noted or tracked in W3C documents. If Anne's work was submitted to and prepared in the context of the WebApps WG, then it is a product of the WG, and there is no obligation to refer to other, prior or variant versions. Referring to an earlier, draft version published outside of the W3C process does not serve any purpose nor is it required by the W3C Process. Legally, we are under no obligation to acknowledge Anne's work. However, we should be honest about the origin of the text and not try to pass off Anne's work as our own. More pointedly: plagiarism is not illegal but that doesn't mean we should do it. If there is a question on the status of the Copyright declaration of the material or its origin, then that should be taken up by the W3C Pubs team. My concern is not about copyright. My concern is about passing off Anne's work as our own. Adam
Re: Re: CfC: publish WD of XHR; deadline November 29
I would think that listing Anne as Editor or Former Editor and listing Anne in an Acknowledgments paragraph should be entirely consistent with all existing W3C practice. But it's not consistent with that existing W3C practice to get all the text for a spec from a document edited outside the WG. Hence, it's a fair suggestion that we have a new look at how authors and editors are credited. (Of course the current W3C-editors also intend to contribute whatever we can to the spec, test suite and process, and I think this discussion risks manufacturing a conflict that doesn't really exist.) -- Hallvord R. M. Steen Core tester, Opera Software
