W3C home > Mailing lists > Public > www-dom-ts@w3.org > June 2001

Re: Recap and action items

From: Ray Whitmer <rayw@netscape.com>
Date: Tue, 05 Jun 2001 16:57:40 -0700
Message-ID: <3B1D71F4.3060502@netscape.com>
To: "Arnold Curt" <Curt.Arnold@hyprotech.com>
CC: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
Arnold, Curt wrote:

>Ray Whitmer wrote:
>
>>I am just fine with not respecifying the DOM specification, 
>>as long as 
>>the test generator uses the DOM specification, not only to 
>>call methods, 
>>but to make sure that in languages like ECMAScript the 
>>correct data type 
>>is being returned by the call.  We know there are significant 
>>problems 
>>today in implementations that need to be detected and should 
>>prevent an 
>>implementation from being counted as a conforming implementation.  I 
>>think you can do this one of several ways:
>>
>>1.  Create specific tests for determining the return types of 
>>a call to 
>>each API in the specification.  In that case, of course, you 
>>have nearly 
>>embedded the return type into the test.
>>
>>2.  When the ECMAScript generator generates a call to any 
>>method with a 
>>return value, with it generate a check to make sure the type of the 
>>returned value is correct.
>>
>>Ray Whitmer
>>rayw@netscape.com
>>
>
>I'd was leaning to option 2 since the the test will be implicit 
>in strongly-typed languages and could automatically be generated 
>for weaker-typed languages.
>
>The two ways I could think of testing return type was to
>either check retobj.nodeType against the expected value (for
>Node's and derivatives) or invoking some property unique
>to the expected type.  Is there some other mechanism
>that we could consider?
>
The particular cases I am most worried about are when an integer is 
returned instead of a string, or vice versa.

This is what gave us fits in the HTML DOM level 2 release that we postponed.

I am not a javascript expert.  I was fiddling around with javascript in 
the two browsers and came up with the following results that might allow 
you to reliably test for a string return type.  If you ask an expert, 
perhaps you will get a much easier test.

The reason that returning the wrong type (integer instead of string) 
causes a problem is that it can cause '+' to do numeric adding instead 
of string concatenation, as the standards would have you expect.  This 
can be used to test a result called rr and determine whether it is 
string or integer (because inequality tests between integers and 
non-integers always return false):

((rr+1+-1)>0)|((rr+1+-1)<=0)

If rr is string, the result of the concatenation will not be an integer, 
so it will fail both comparisons and return 0.
If rr is integer or boolean, the result of the addition will be an 
integer, so it must pass one of the comparisons and return 1.

I would assume that similar tests could be devised for other situations, 
but this takes care of the one that worries me most.

It works for me in mozilla and IE.

Ray Whitmer
rayw@netscape.com
Received on Tuesday, 5 June 2001 19:54:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:44 GMT