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

Oops. Adding Anne.

> -----Original Message-----
> From: Sunava Dutta
> Sent: Thursday, June 19, 2008 2:12 PM
> To: 'Ian Hickson'; Zhenbin Xu; public-webapps@w3.org
> Cc: IE8 Core AJAX SWAT Team
> Subject: <New: Tracking Issues in XHR that we raised>RE: <Was: Further
> LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite
>
> 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:37:10 UTC