W3C home > Mailing lists > Public > www-tag@w3.org > April 2009

RE: Versioning and HTML -- test cases

From: Larry Masinter <masinter@adobe.com>
Date: Wed, 29 Apr 2009 05:35:24 -0700
To: "www-tag@w3.org WG" <www-tag@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118CD740AA6@nambx04.corp.adobe.com>
This is getting far away from the discussion of versioning.

The connection is the question of whether testing HTML today 
could ensure that the specification would never need versioning.

# I agree with Ashok.  If the specification is written with explicit
# MUST's (or mandatory rules) in it and the test cases are tied to
# these statements (or rules) then the testing and CR experience can
# be directly related back to the specification.

Test cases are valuable. Testing is indeed an important quality aspect
for standards, and we shouldn't back off from encouraging them.

But question we were discussing is whether test cases ENSURE that the
spec has been implemented, or is implementable.  Test cases don't, and
can't, make such a guarantee.

It isn't possible to test all combinations and situations.  It isn't
practical to write test cases for specifications that describe visual
effects and which allow the necessarily leeway needed for the spec to
be useful in a wide variety of circumstances.  It isn't possible, in
general, to write test cases for specifications which are described by
the algorithm by which something is to be implemented, since two
algorithms can have mainly the same effect in most cases but can
handle edge cases differently, and test cases are "black box" testing.

Even if full testing were possible, writing test cases for
specifications and getting the test cases agreed and validated is
harder and more time consuming than writing the specification or
implementing the specification in the first place.

So I don't think the fact that there are test cases for HTML is
proof that HTML -- after HTML5 -- will never again need changes 
that are restrictions, clarifications, or incompatible modifications.

Received on Wednesday, 29 April 2009 12:36:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:28 UTC