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

Reply via email to