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
