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

RE: Updated test-to-java, etc

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Thu, 25 Oct 2001 09:56:30 -0600
Message-ID: <70E215722F6AD511820A000103D141D40AA62A@thor.aeathtl.com>
To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
[mb] Would be more informative if you actually identified the tests.  The tests have been written by a couple of different folks, and then 
translated into XML, primarily by a guest researcher who is no longer with us.  On our side, we have to track from original source, through 
the translation to XML, and then the test suite translation.  This is much easier if you can identify which tests you are having problems with in 
addition to the actual problem (problem definition above is okay, but which tests?)

If you do a multifile search for <member> in your editor, you'll see all the tests that populate an collection.  The ones where the values don't seem to have any commonality, one value "FALSE", one
value "#document" are typically using list comparison when separate comparisons would be better.  If you notice the time, it was getting seriously late when I got the tests to build. 

[mb] I agree that level 3 should not be tested, but I would suspect level 1 and 2 should be supported.  We went back and forth with this type of test.  One 
method would be to break it out into different combinations, supporting the atomic method of testing.  Any thoughts on whether multiple assertions 
within a test would be better than many tests, where different combinations are tested.  

Unless I misunderstand the test, the whole premise is wrong.  The only feature that an implementation needs to return true from hasFeature or isSupported is "Core".  What isSupported("HTML","1.0")
returns is irrelevant.

[mb] I'm not finding any documentation trails indicating what you changed and what you didn't.  I thought we agreed early on that e-mail was not 
the way to track this type of info.  Isn't there a metadata tag available for modified by?  Or, perhaps better documentation when the files are committed 
to CVS -- the one comment applied to all files isn't very informative, and with so much going on, it's difficult to follow the e-mail trail.

I definitely took liberties in the bulk modifications to get the files to compile which would not be good practice after an initial build succeeds.  I did try to preserve the intent of the original
test.  If you want a line by line change summary, that can obtained from the CVS and if really important to you, I can pull a copy and annotate it.
Received on Thursday, 25 October 2001 11:58:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:03 UTC