Re: DOM 1 Test Problems

Joe,

Thanks for your feedback.

I need to dig through the archives to supply pointers to the resolutions 
of some of the issues you raise. Some other comments are inlined.

On Monday, May 27, 2002, at 08:33 PM, Joe Schafer wrote:

> Well, I downloaded the XML and DOM specs and built me an XML parser and 
> DOM implementation.
> Then I found the DOM TS and hooked it up so it would test my 
> implementation from JsUnit.
> That's when I ran into a few issues.
>
> First, the nodeprocessinginstructionsetnodevalue test, sets the 
> WillBeModified flag wrong so later the processinginstructiongetdata 
> test fails.
>
> Second, JsUnit requires that null be retrurned from nodeValue in 
> several cases.  However, if we concider ECMA script with DOMString 
> mapped to ECMA's string type, then we are requiring that an attribute 
> of DOMString type will produce a value that is not a DOMString !!!!  
> While that may be acceptable, the DOM spec says nothing about nodeValue 
> producing a value that is not a DOMString.  In fact it never says 
> anything about null being different from an empty string.  There needs 
> to be support on the ECMA side of the house to support an 
> implementations that conciders ECMA's null to NOT be a DOMString.  In 
> such an implementation, a null DOMString is the same thing as an empty 
> string.  ECMA null's will never be passed as a DOMString.  When one 
> conciders that DOMString has been made a value type in later DOM 
> versions and the additional overhead of having to continually look for 
> ECMA null's passed as DOMStrings, there is a strong case for an  
> implementation that does not allow ECMA null's to be passed as 
> DOMStrings.
>
> This issue affects the AssertNull function, which can be fixed with a: 
> aVar===null || aVar==='"" test instead of the aVar===null test that 
> currently exists.  It also affects the hasFeature tests.  In this case 
> the domimplementationfeaturenull test will fail but the 
> domimplementationfeaturenoversion test will work.  However with this 
> implementation they are the same test.  So there needs to be a way to 
> turn off (or make it pass) the domimplementationfeaturenull test. 
> Another test that is affected is testparseintolistofelements.  This one 
> uses a comparison to null that also fails.
>
> Another issue is the the raising of NO_MODIFICATION_ALLOWED_ERR when 
> the nodeValue attribute is set on Entity, Entity Reference, Document 
> Type and Notation nodes.  Yes the DOM spec says these operations have 
> no effect.  But it also says that they should raise 
> NO_MODIFICATION_ALLOWED_ERR when the node is readonly.  Since these 
> four node types are readonly by definition, one would expect the tests 
> to be looking for NO_MODIFICATION_ALLOWED_ERR.  However they don't,  
> they just check that value is unchanged.
>
> A concideration is that the elementremoveattribute and 
> elementattributerestoredefaultvalue both test the same attribute 
> ("street").  It would be better if the elementremoveattribute test 
> worked on an attribute that did not have a default attribute.  At least 
> then the tests would be testing different things.
>
> A test of passing a DocumentFragment node to the replaceChild operation 
> would also be nice.
>
> All in all the test suite is quite nice, but now that I have my 
> implementation passing all the tests, I NEED MORE TESTS !!!  When will 
> the DOM Level 2 tests be completed ???   For that matter, why are the 
> tests not generated ???
>
[dd] The DOM TS is publically produced, and anyone interested is welcome 
to help. We're currently working on the next version of the TS you 
downloaded, with HTML tests and an updated framework (a different 
version of JsUnit) and after that, we'll release the TS for level 2. 
Visit http://www.w3.org/DOM/Test to see how you can contribute.

> Given the simple (and I mean SIMPLE) structure that the DOM defines, 
> why aren't, at least a large portion, of the simple test cases  
> generated from the specification ????   It sure would not be difficult 
> to write a routine to generate things like 'Attempt to add every node 
> type as a child to every other node type', or 'Create all possible 
> legal node structures from 1 to N levels deep, clone them and compare 
> the clones for equivelence', or 'Generate all possible modification 
> sequences for a set of 1 to N attributes on a single element',  or 
> 'Generate sequences of legal and illegal names and attempt to create 
> nodes using the names', or 'Generate tests for all the possible 
> document mismatch errors', etc. etc,  etc.
>
[dd] Also something being looked into, however our main problem is 
resources. We've been thinking along using an XSLT transform to generate 
test directly from the specification along the lines you mention. This 
would give us a very good starting point and provide us with a skeleton 
on which we could biuld the DOM TS.

Feel free to mail me and I'll include you in the loop once we start 
working on it. If you have ideas in the meantime, please use this list. 
Comments/proposals are always welcome.


> Only 290 tests ?????  That was easy ......
>
[dd] There'll be lots more from the next version onward.

Again, thanks for your comments.

/Dimitris


> Joe Schafer
> jschafer@iquest.net
>
>
>

Received on Monday, 27 May 2002 14:54:34 UTC