- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 17 Jun 2008 09:40:02 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: Zhenbin Xu <Zhenbin.Xu@microsoft.com>, 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>
Ian Hickson wrote:
> On Tue, 17 Jun 2008, Zhenbin Xu wrote:
>>>> I am not sure if I understand your question. responseXML.parseError
>>>> has the error information
>>>> http://msdn.microsoft.com/en-us/library/aa926483.aspx
>>> Oh, I assumed Sunava meant a conforming Document object was returned.
>>> A parseError-type object would be what I had in mind, yes. However, if
>>> we do this, then we should specify it. If we don't specify it, I'd
>>> rather have an exception.
>> The spec can simply state that a conforming document object is returned,
>> which includes out-of-band error information. This is what IE does today
>> and is a very reasonable approach that allows rich error information for
>> debugging.
>
> I don't believe it is conforming for Document objects to have parseError
> attributes, but I could be mistaken -- is there a spec for parseError?
> Even if there isn't, though, I agree that it is a generally good solution
> to the problem, I'm just saying that we should specify it, so that UAs
> can be standards-compliant and support it interoperably.
I think we have two choices for how to handle parse errors here:
1. Mandate that a Document object containing a .parseError property
is returned for .responseXML
2. Mandate that null is returned
I think some hodgepodge solution of the two is likely just going to be
harder to code against for developers.
Are we comfortable adding the .parseError object to the XHR spec? Feels
like spec creep to me unfortunately.
/ Jonas
Received on Tuesday, 17 June 2008 16:44:02 UTC