RE: XHR LC comments

Inline...

> -----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