W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

RE: responseXML/responseText exceptions and parseError

From: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
Date: Thu, 19 Jun 2008 14:42:16 -0700
To: Jonas Sicking <jonas@sicking.cc>
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>
Message-ID: <72F767ADE7C63540BE69CD2722A41F440E9C93E14D@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Sorry I accidently deleted part of reply. Inline...

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Thursday, June 19, 2008 2:17 PM
> To: Zhenbin Xu
> Cc: Anne van Kesteren; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
> webapps@w3.org
> Subject: Re: responseXML/responseText exceptions and parseError
>
> 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] Indeed it would already be very useful if XHR1 is to summarize
behaviors of all major implementations today, and document the common behaviors.
In which case the spec should try to accommodate all major browsers and
leave controversial parts to XHR2. This is why we suggested the "null or exception"
language.




> > [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:42:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:26 GMT