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
