RE: XHR LC comments

Inline...

> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Saturday, May 17, 2008 2:04 AM
> To: Julian Reschke
> Cc: Sunava Dutta; Anne van Kesteren; Web API WG (public)
> Subject: Re: XHR LC comments
>
>
> 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.

[Sunava Dutta] Can I have a link to this? I can't find it. Thanks!
Btw, we discussed the possibility of having the test suite ready before CR (see below). I think that's wise given that you mentioned that there are many cases where interoperability has not been reached? (or a convergence plan is not in place?) Our XHR test is going to be running the test suite in LC to see where interop doesn't exist and weigh in with our thoughts where we can to help.
http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0019.html
In response to our mail:
> 2) In fact, on that note, we're interested to see the test suite be
> linked, normatively if necessary.
Charles said
"Yes. I think this is a valuable piece of feedback. Currently W3C process
doesn't require test suites until you're trying to get out of CR and I
think it would be better to have them earlier. I would
like the group to start checking the test cases we have against the spec
and formally agreeing them to facilitate this linkage during last call. It
slows down the LC period, but it should make CR easier and reduce the
possibility of reverting from CR."

)

>
> Regards,
> Maciej
>