W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: XHR LC comments

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 19 May 2008 15:14:26 -0700
Message-ID: <4831FBC2.1070909@sicking.cc>
To: Sunava Dutta <sunavad@windows.microsoft.com>
CC: Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Maciej Stachowiak <mjs@apple.com>, "Web API WG (public)" <public-webapi@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>

Sunava Dutta wrote:
>>> setRequestHeader() currently simply is broken. We should deprecate it,
>>> and add new methods with well-defined semantics:
>>> - removeHeader(...) (or specify set with null to mean remove)
>>> - addHeader...
>>> - getHeader...
>> "Deprecating" a method does not help implementations converge. Besides,
>> for typical usage there's no issue in using this header at all.
> [Sunava Dutta] I agree with Anne here. Deprecating an existing
> implementations and re-engineering XHR is something we just cannot
> accept. This spec should be designed to reflect reality and seek
> interoperability for each and every single section/method/event with
> at least one (I think the W3C mandates two?) existing implementations.
> That does not mean the entire spec is aligned with FF or IE, but it
> should be harmonious at any instance with one existing implementation.

There is absolutely no W3C mandate that a spec is compatible with any 
existing implementations in order to reach the earlier milestones in the 
standardization track. Not sure where you got that idea. It would be 
very strange if there was a requirement to have implementations in order 
to reach LC, when W3C is discouraging implementations at that stage.

Also, I personally don't care at all which UAs the various features of 
spec is compatible with. Or if it's not compatible with any UA. What I 
care about is that the spec is compatible with the web, and in the cases 
where the web doesn't care, that it's as useful and simple as possible.

/ Jonas
Received on Monday, 19 May 2008 22:16:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC