Zhenbin Xu wrote:
Inline...
-----Original Message-----
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2008 3:37 PM
To: Anne van Kesteren
Cc: Zhenbin Xu; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
[EMAIL PROTECTED]
Subject: Re: responseXML/responseText exceptions and parseError
Anne van Kesteren wrote:
On Tue, 17 Jun 2008 10:29:12 +0200, Zhenbin Xu
<[EMAIL PROTECTED]> wrote:
Technically because all other XHR methods/properties throw
exceptions
in case of state violation, exception for responseXML/responseText
is
better.
The reason these don't throw an exception anymore is actually
documented
on the public-webapi mailing list. Nobody else provided additional
information at the time:
http://lists.w3.org/Archives/Public/public-
webapi/2008Feb/thread.html#msg94
Regarding parseError, since the parseError object is not part of DOM
Core and nobody but Internet Explorer supported it, it's not part of
XMLHttpRequest.
Agreed.
[Zhenbin Xu] Regardless what different browser does today, rich parsing
error is an important feature for developers. I have found it can pinpoint
the exact problem that otherwise would have been difficult to identify when
I sent incorrectly constructed XML file.
And given that the goals is to define a useful spec for future
XHR implementations, we should define how rich parser error is
surfaced instead of omitting it because nobody but IE supported it.
It is even more important we define it in the XHR spec because it is not
part of DOM Core. Otherwise such a key piece would be lost and we will
have diverging implementations.
The goal of XHR Level 1 was to get interoperability on the feature set
that exists across the major implementations of XHR today, so I don't
think parse error information fits the bill there, but it sounds like a
great feature to look into for XHR Level 2.
If we change DOM Core to say that documents with a
namespace well-formedness violation are represented by an empty
Document
object with an associated parseError object I suppose we could update
XMLHttpRequest to that effect.
If we return null now people will use that to check for well-formedness
checks. If we in the next version of the spec then said that an empty
document with .parseError set should be returned those pages would
break.
So if we are planning on doing the parse error thing then I think we
should define that an empty document is returned.
Though I think it's more friendly to JS developers to return null.
Otherwise they have to nullcheck both .responseXML as well as
.responseXML.documentElement in order to check that they have a valid
document.
And if I understand it right IE would have to be changed to be
complient
with the spec no matter what since they currently return a non-empty
document.
/ Jonas
[Zhenbin Xu] IE does returns an empty document. responseXML.documentElement
is null but responseXML is not null.
A typical readyState handler can be written this way:
xhr.onreadystatechange = function()
{
if (this.readyState == 4 && this.status == 200)
{
var x = this.responseXML;
if (x.parseError.errorCode != 0)
{
alert(x.parseError.reason);
return;
}
alert(x.documentElement);
}
}
I don't see why this is not friendly. It is more comprehensive and gives
more information than a simple null check, which contains no information
about what exactly is the parsing error (e.g. which open tag doesn’t match
which end tag, etc.).
Won't that throw when XHR.responseXML is null, such as when the
mime-type is something completely different from an XML document?
But I absolutely agree that a null check does not give enough error
information to usefully do debugging. I was merely saying that a null
check should be enough to check for if parsing succeeded. The above is
probably not what you would want to do on an end user site since a user
won't care which end tag was not properly nested.
/ Jonas
