Re: Updated test-to-java, etc

----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: <www-dom-ts@w3.org>
Sent: Thursday, October 25, 2001 11:56 AM
Subject: RE: Updated test-to-java, etc


> [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?)
>
> [ca]
> 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]  Yes, we are all putting in long hours getting this to work -- all the
more reason for giving each other better clues for picking up
where the other left off...

> [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.
>
> [ca]
> 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] See additional e-mail for more details.

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

[mb] There shouldn't be any difference between now and after an initial
build succeeds.  There are good reasons for using CVS -- let's try to make
it work for us.

--Mary

>

Received on Thursday, 25 October 2001 12:38:55 UTC