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

<New: Tracking Issues in XHR that we raised>RE: <Was: Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

From: Sunava Dutta <sunavad@windows.microsoft.com>
Date: Thu, 19 Jun 2008 14:11:53 -0700
To: Ian Hickson <ian@hixie.ch>, Zhenbin Xu <Zhenbin.Xu@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
CC: IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Message-ID: <083D18C6B9B71F4CBCA7B76D97B748310C80CAC211@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

Thanks Ian, Zhenbin for clarifying the issues and a continuing very productive discussion.
Meanwhile, I'm summarizing some of our requests for the editor based on issues we've had an opportunity to clarify...There are many conversations going on and I'd hate to see points getting lost and would like the specs/test cases updated for issues where discussions are not ongoing.


-Ongoing discussion: Specify the parseError attributes for Document Objects or specify this can be sent out of band. This could be something we don't have to hold the XHR spec back for as long as we make a note in the specification that this is pending. There are people currently talking for and/or against it. Zhenbin is articulating IE's point.

- Throwing exceptions on state violations is easier to understand and we should change the spec to reflect this. (for the sake of a consistent programming model). The spec should have INVALID_STATE_ERR exception (the exact language can be worked out)  if a site is expecting an exception and gets a null as this would not work if the developer is trying to write a wrapper object in XHR. I haven't heard any strong objection here or compelling argument against it that's been sustained.

- As Ian mentions, XHR should not require any particular level of DOM support. Along those lines we should remove DOM dependencies that do DOM tests from the spec/tests or at least change the test cases to use getElementByTagName instead of getElementbyID.


> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Tuesday, June 17, 2008 1:51 AM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> webapps@w3.org
> Subject: RE: <Further LC Followup from IE> RE: Potential bugs
> identified in XHR LC Test Suite
>
> 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.
>
>
> > > Not really; if the script is expecting an exception, and receives
> null
> > > instead, then they'll just get an exception as soon as they
> > > dereference the object, which in almost all cases will be straight
> > > away.
> >
> > [Zhenbin] I should explain the scenario I talked about. For instance,
> if
> > I am to write a wrapper object myXHR, it makes a difference for me
> when
> > I do the following
> >
> >     myXHR.responseXML
> >         if (!_innerResponseXML)
> >       {
> >                 try
> >                 {
> >                    _innerResponseXML = _innerXHR.responseXML;
> >                 }
> >                 catch (e)
> >             {
> >                 _myexception = e;
> >                 return _dummpyResponseXML;
> >             }
> >         }
> >         return _innerResponseXML;
> >
> > My try catch would not catch null. And the exception would be passed
> on
> > to my callers, which is not what I wanted.
>
> Indeed.
>
>
> > > > If we are going to spec it to accommodate all existing browsers,
> we
> > > > would want to make it "return null or INVALID_STATE_ERR
> exception".
> > >
> > > We want interoperable behaviour, so defining it in this way would
> be a
> > > bad idea. (I don't really have an opinion either way about
> exception
> > > vs null, but it seems that we should just pick whatever is most
> > > commonly implemented, which I'm guessing is what Anne did here.)
> >
> > Fair enough. So let's pick one.
> >
> > What is "commonly implemented"? Is it largest browser market share?
>
> Since the cost to implementations for fixing the problem is independent
> of
> the size of the user base, it would be based just on the number of
> independent implementations.
>
>
> > Is it number of enterprise applications written on top of particular
> > browser?
>
> All the browsers want to be compatible with the Web, so if there are
> mroe
> Web sites depending on the exception behaviour than the null behaviour,
> then we clearly should do the exception behaviour. And vice versa. Do
> we
> have any good numbers on this? (That there are widely deployed browsers
> that return null instead of throwing an exception tends to suggest that
> Web pages don't depend on either behaviour; we'd probably need evidence
> to the contrary to decide one way or the other based on compatibility.)
>
>
> > Is it the number of browers, in which case I hope my fictional
> > home grown personal browser gets a vote :-)
>
> Obviously fictional browsers aren't relevant, since the cost of fixing
> a
> fictional browser is zero.
>
>
> > From a pure technical point of view, predictably throw exception on
> > state violations is easier to understand.  I hope you would agree
> there
> > is value to change spec for the sake of consistent programming model
> > (which happens to be the IE model).
>
> Indeed.
>
>
> > Did the spec call out that responseXML returned from XHR should have
> > equivalent DOM support as UA's object?  If it is, that would be a
> good
> > topic for us to debate about.
>
> I believe the spec just says that you return a Document object; it is
> the
> lack of a distinction between different Document objects that requires
> the
> level of support to be the same. As you said, a consistent programming
> model has value.
>
>
> > I disagree that because DOM Level 3 is 3+ yr old spec that every UA
> has
> > to support it in order to be XHR compliant, if that is what you
> implied.
>
> I didn't mean to imply that. I don't think XHR should require any
> particular level of support.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.
> fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
> ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
> .;.'
Received on Thursday, 19 June 2008 21:18:23 GMT

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