W3C home > Mailing lists > Public > public-webapi@w3.org > June 2008

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

From: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
Date: Tue, 17 Jun 2008 01:29:12 -0700
To: Jonas Sicking <jonas@sicking.cc>
CC: Sunava Dutta <sunavad@windows.microsoft.com>, Web API public <public-webapi@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <72F767ADE7C63540BE69CD2722A41F440E99820799@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

Exceptional situation in general doesn't hinder interoperability. It only
becomes an issue if it is clearly stated in W3C spec and used as
a way to measure if UA is compliant.

We have provided our feedback to write spec in a away all current browsers
are complaint. If the general sentiment is to pick one model, then lets pick
the exception model, which is the model original XHR inventors picked.

Technically because all other XHR methods/properties throw exceptions
in case of state violation, exception for responseXML/responseText is better.
If original XHR picked the null model, then we should go null model.
The important thing really is consistency, thus predictability.


Thanks!
Zhenbin


> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Monday, June 16, 2008 2:13 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> webapps@w3.org
> Subject: Re: <Further LC Followup from IE> RE: Potential bugs
> identified in XHR LC Test Suite
>
> Zhenbin Xu wrote:
> > The issue of return "null or an exception" is simply a compromise
> > here. IE would throw an exception for state violations. Accessing
> > responseXML before open() is a state violation so it would trigger
> > exception. Other browsers may return null in such situation.  In
> order
> > to accommodate all browsers, the spec would have to be rewritten in
> > some way.
>
> Please note that it is not a goal for the spec to be written in such a
> way that all existing browsers are conforming to the spec. It turned
> out
> that it was impossible to write a spec with that goal while still
> keeping the spec useful. So we no longer try to "accomodate all
> browsers", but instead write a spec that leads to interoperability
> between browsers.
>
> > We would certainly love to have the spec change to "MUST throw
> > INVALID_STATE_ERR exception", which is consistent with other
> > INVALID_STATE_ERR cases.  For instance, the spec says if send() is
> > called before OPENED, it should trigger  INVALID_STATE_ERR exception.
> > Another example is that user agent must raise INVALID_STATE_ERR if
> > "status" is not available. responseText and responseXML are the
> > outlier in the spec.
>
> Personally I think it makes more sense to return 'null' from
> .responseXML. We at mozilla have not had any interoperability problems
> with this behavior. Exceptions are better left for exceptional
> circumstances.
>
> However I can't say that I think the behavior is very important to me
> one way or another, as long as it's usefully defined.
>
> Best Regards,
> Jonas Sicking
>
Received on Tuesday, 17 June 2008 08:30:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 June 2008 08:30:04 GMT