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

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

From: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
Date: Thu, 19 Jun 2008 18:48:36 -0700
To: Jonas Sicking <jonas@sicking.cc>, Sunava Dutta <sunavad@windows.microsoft.com>
CC: Ian Hickson <ian@hixie.ch>, "public-webapps@w3.org" <public-webapps@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Message-ID: <72F767ADE7C63540BE69CD2722A41F440E9C93E225@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>


> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Thursday, June 19, 2008 2:38 PM
> To: Sunava Dutta
> Cc: Ian Hickson; Zhenbin Xu; public-webapps@w3.org; IE8 Core AJAX SWAT
> Team
> Subject: 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
>
> Sunava Dutta wrote:
> > 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.
>
> Sounds good to me. We have an informative "Not in this specification"
> section already, sounds like a good idea to add there.
>
> > - 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.
>
> I do think there has been some disagreement here. Anne has commented on
> reasons for returning null rather than throwing an exception, and I
> think I agree with him. I think the correct cause of action here is to
> raise an issue in the issue tracker.
>

[Zhenbin Xu] I am not familiar with the process here.  How does issue
gets resolved when it is in issue tracker?  We have enough debate already
that there is technical merit to throw exception rather than null. It is
not going to be productive for us to keep spending time on it.

Since this doesn't impact main stream scenario, most JS developers don't
need to worry about the behaviors. I once again propose the spec simply
state "null or exception" with sufficient explanations. If we all agree
then we can move on to more important issues.




> > - 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.
>
> Sounds fine to me. We could also include tests that first check if
> getElementById is implemented at all and if so tests that it functions
> properly.
>
> The nice thing about testing getElementById is that it not only tests
> the DOM, but also tests that ID parsing works properly.
>
> But this way a DOM L1 implementation still passes fine.
>
> / Jonas
Received on Friday, 20 June 2008 01:49:09 GMT

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