On May 17, 2008, at 1:03 AM, Julian Reschke wrote:
Sunava Dutta wrote:
...
At this point, I'm not sure why we're bothering with XHR1 at all.
It is
*not* what the current implementations do anyway.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like
to understand it better. We haven’t had a chance to run the latest
test suite yet but expect the test suite to be compliant with at
least two existing implementations. Do you mean the XHR 1 draft is
not interoperable with existing implementations?
...
Absolutely. Everytime I check something that is of interest to me it
turns out that there is no interop, and that only some or even none
of the browsers works as specified.
We decided long ago (and subsequently reaffirmed) that instead of
leaving the spec so vague that all existing implementations are
automatically compliant, we would define a shared interoperable
behavior so that implementations can converge. It should not be news
to anyone that implementations are not automatically 100% compliant.
Examples:
- Support for HTTP extension methods: IE violates the SHOULD level
requirement to support extenstion methods. Opera silently (!!!)
changes extension method names to "POST".
- setRequestHeader: none of the browsers throws an exception when
setting the header to null. Some do something useful (removing the
header), some treat it like an empty string, some seem to set the
valoue to the string "null".
I'm also concerned that the spec proposes behaviour that leads to
silent data loss, although it's totally unclear why this is needed
for interoperability (such as when a DOM to be serialized has no XML
representation).
It seems that what's needed here is more work on the test suite. LC
is way too early.
By W3C Process, the test suite is supposed to be developed during the
CR period. So by having one at all before LC, we are ahead of schedule.
Regards,
Maciej
