Sunava Dutta wrote:
Inline...
-----Original Message-----
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
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
