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

Inline...

> -----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.

[Sunava Dutta] Sorry, I'm not quite sure what you mean here?
>
> > - 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.
>
> > - 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 02:08:17 UTC