- From: Joe Schafer <jschafer@iquest.net>
- Date: Mon, 27 May 2002 13:33:39 -0500
- To: www-dom-ts@w3.org
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 ??? 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. Only 290 tests ????? That was easy ...... Joe Schafer jschafer@iquest.net
Received on Monday, 27 May 2002 14:33:15 UTC