W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 16 Jun 2008 14:13:08 -0700
Message-ID: <4856D764.5030001@sicking.cc>
To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
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>

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 

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 Monday, 16 June 2008 21:17:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:09 UTC