- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 19 Jun 2008 14:17:09 -0700
- To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
- CC: Anne van Kesteren <annevk@opera.com>, Sunava Dutta <sunavad@windows.microsoft.com>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Zhenbin Xu wrote: >>> [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. > > [Zhenbin Xu] Did something happen to your reply here? > [Zhenbin Xu] The way it was designed is that responseXML is always not null once > it is in OPENED state. I don't think IE currently give out rich error information > about mimetype mismatch but the design allows it to be exposed on responseXML, if > necessary. Ah, good to know. I'm not particularly a big fan of this design, feels more logical to me to not return a document object if no document was sent. But I guess it depends on how you look at it. / Jonas
Received on Thursday, 19 June 2008 21:17:20 UTC