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

Inline...

-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch]
Sent: Wednesday, June 11, 2008 9:34 PM
To: Sunava Dutta
Cc: 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


Some quick comments on some of the comments regarding the tests:

On Wed, 11 Jun 2008, Sunava Dutta wrote:
>
> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm

>
> When Parsing Error happens, IE would still retain responseXML and put
> error information on the object.  Isnt this better than null as there�s
> more relevant information for the web developer?

How does one distinguish a document returned with parse error information
from one that happens to look like a parse error but was well-formed?

I wouldn't mind including more information but it seems like it should be
out-of-band.

[Zhenbin]  I am not sure if I understand your question. responseXML.parseError
has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx



> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm

>
> The test is expecting us to return NULL in case open() has not been
> called.  We throw an exception in IE.  I�d pre fer if the spec says
> �MUST return null OR an exception� otherwise I fear sites today will be
> broken.

If a site is expecting an exception and gets null, then they'll get an
exception when they try to dereferene the null, so in most cases it seems
like this would work anyway.

[Zhenbin] Properly written sites would have no problem one way or the other.
However if someone is writing a wrapper on top of XMLHTTP, clearly it would
make a difference on how to expose wrapped properties. OTOH they likely already
have handled both cases (currently IE throws exceptions and others return null).
If we are going to spec it to accommodate all existing browsers, we would want
to make it "return null or INVALID_STATE_ERR exception".  If we are going to
spec it "the right way", then I think throw exception is a more consistent design (see
my reply to Jonas).



> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm

> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm

>
> This test really doesn�t test XHR here. It seems to be focused on
> manipulating the XML DOM. (I also don�t think Microsoft.XMLDOM supports
> getElementById for an XML document FYI). Also, if I'm barking up the
> wrong tree here please let me know!

I think it's important that we test that the DOM returned from XHR is DOM
Core conformant just like any other, so this seems like an important and
relevant testing area for XHR.

[Zhenbin] That is not necessarily a good idea because you would then have to
mandate which level of DOM Core support is required. And if the spec requires
DOM level 3, that is big barrier for new user agent that wants to be compliant
with XHR spec.

getElementById requires DOM Level 2. At the least the testing case can be
changed to use getElementByTagName, which is DOM level 1.


--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 16 June 2008 20:12:57 UTC