W3C home > Mailing lists > Public > public-css-testsuite@w3.org > October 2007

Process proposal for modifying tests

From: Grant, Melinda <melinda.grant@hp.com>
Date: Thu, 4 Oct 2007 19:02:13 -0000
Message-ID: <78A3602ADF54BA4EAB53F378BF55588B01D5A42D@G3W0067.americas.hpqcorp.net>
To: <public-css-testsuite@w3.org>
Once tests have been published, external testsuites including the
testsuites of other standards bodies may rely on them.  There is the
concern that this may lead to problems if tests are changed subsequent
to their initial publication.
For example, if Implementation A is certified as qualified by passing a
test which calls for the underlining of images, and Implementation B is
later certified as qualified by passing a changed version of the same
test file, but which now calls for images not to be underlined,
Implementations A and B will not interoperate wrt underlining of images.
One answer would be to establish a process whereby a test file would
only change by having its contents replaced with an explanation of why
the original test needed to be removed or modified, and a pointer to the
modified test(s).
Another possibility might be to never revise tests in dated directories,
and clearly communicate that the contents of dated dirs are frozen and
the tests in 'current' dirs are subject to change...  The problem with
this approach is that I think people will expect tests on the W3 site to
be correct, and won't in general notice whether they're in a 'current'
or dated directory.  So I prefer the first option.
Would this approach be workable, or how else might we mitigate this
Best wishes,


Melinda S. Grant	
Connectivity Strategist
Imaging & Printing Group


Melinda.Grant@hp.com <mailto:melinda.grant@hp.com> 


(image/gif attachment: hm_logo.gif)

Received on Thursday, 4 October 2007 19:03:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:17 UTC