RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Inline...

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Sunday, June 15, 2008 11:46 PM
> 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 Sun, 15 Jun 2008, Zhenbin Xu wrote:
> > Ian wrote:
> > > On Wed, 11 Jun 2008, Sunava Dutta wrote:
> > > >
> > > > When Parsing Error happens, IE would still retain responseXML and
> > > > put error information on the object.  Isnt this better than null
> as
> > > > there�s more relevant information for the web developer?
> > >
> > > How does one distinguish a document returned with parse error
> > > information from one that happens to look like a parse error but
> was
> > > well-formed?
> > >
> > > I wouldn't mind including more information but it seems like it
> should
> > > be out-of-band.
> >
> > 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.
>

[Zhenbin]  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.


>
> > > > The test is expecting us to return NULL in case open() has not
> been
> > > > called.  We throw an exception in IE.  I�d pre fer if the spec
> > > > says �MUST return null OR an exception� otherwise I fear sites
> > > > today will be broken.
> > >
> > > If a site is expecting an exception and gets null, then they'll get
> an
> > > exception when they try to dereferene the null, so in most cases it
> > > seems like this would work anyway.
> >
> > Properly written sites would have no problem one way or the other.
> > However if someone is writing a wrapper on top of XMLHTTP, clearly it
> > would make a difference on how to expose wrapped properties.
>
> 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.




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


[Zhenbin]  Fair enough. So let's pick one.

What is "commonly implemented"? Is it largest browser market share?
Is it number of enterprise applications written on top of particular browser?
Is it the number of browers, in which case I hope my fictional home grown
personal browser gets a vote :-)

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



>
> > > I think it's important that we test that the DOM returned from XHR
> is
> > > DOM Core conformant just like any other, so this seems like an
> > > important and relevant testing area for XHR.
> >
> > That is not necessarily a good idea because you would then have to
> > mandate which level of DOM Core support is required. And if the spec
> > requires DOM level 3, that is big barrier for new user agent that
> wants
> > to be compliant with XHR spec.
> >
> > getElementById requires DOM Level 2. At the least the testing case
> can
> > be changed to use getElementByTagName, which is DOM level 1.
>
> I think expecting DOM Level 3 is the least of our worries -- after all,
> that's a 3+ year old spec. So testing just DOM Level 2 is really not a
> problem as far as I can tell. However, I agree that it would make sense
> to
> make the test pass if the UA didn't support that level of DOM on
> "regular"
> DOM objects too. The key is just to make sure that the objects returned
> by
> XHR are of equivalent DOM support as the rest of the UA's objects.
>

[Zhenbin]  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 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. XMLHTTP
has proven to be extremely valuable for the past years without providing DOM
level 3 support or equivalent DOM support between UA and responseXML.



> --
> Ian Hickson               U+1047E                )\._.,--....,'``.
> fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
> .;.'

Received on Tuesday, 17 June 2008 08:17:46 UTC