Re: XHR LC comments

Sunava Dutta wrote:
> 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?

No, I mean "able to run the javascript that exists on pages on the web". 
So for example if there is an aspect to a feature that no, or very few, 
web pages use, then I don't think we need to pay attention to what UAs 
do today and instead make the best possible spec based on technical 
considerations.

Figuring out what aspects webpages do or don't use is hard of course. 
But often there are indications as well as implementation experience.

> Getting back to more specifics, if we're talking about compatibility I
> absolutely believe the spec should be relevant to existing
> implementations.

What do you mean by "relevant to existing implementations". And why do 
you think that?

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

It is in fact quite common when you start looking at the details of the 
various features that implementations behave very differently. So in 
those details we should in my opinion use the strategy I described above.

/ Jonas

Received on Monday, 19 May 2008 22:55:02 UTC