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

RE: XHR LC comments

From: Sunava Dutta <sunavad@windows.microsoft.com>
Date: Mon, 19 May 2008 15:21:46 -0700
To: Jonas Sicking <jonas@sicking.cc>
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>
Message-ID: <083D18C6B9B71F4CBCA7B76D97B748310C74245D6D@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Monday, May 19, 2008 3:14 PM
> To: Sunava Dutta
> Cc: Anne van Kesteren; Julian Reschke; Maciej Stachowiak; Web API WG
> (public); IE8 Core AJAX SWAT Team
> Subject: Re: XHR LC comments
> 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
[Sunava Dutta] Compatible with the web sounds very nice and is something I think I share with you. I think you mean compatible with browsers who enable the technologies when you mean compatible with the web?
Getting back to more specifics, if we're talking about compatibility I absolutely believe the spec should be relevant to existing implementations. I'm amenable to what Maciej said when he mentioned that in the case (I'm assuming this is a rarity) where the implementations are doing whacky things or doing nothing at all, it makes sense to work together to identify a way/solution that will allow for convergence.
Thanks for pointing out there is no mandate or guidelines for having two implementations in CR. I misunderstood something Chris had mentioned awhile back. -:).
Received on Monday, 19 May 2008 22:22:31 UTC

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