[Design] Test case modularization

* Modularization of test cases.  The problem is that the DOM Spec
explicitly calls out exceptions to allow multiple implementation systems
to be compliant.  For example, in DOM Level 1 there are notes for
systems that do not support the concept of reporting exceptions and
implementations that are HTML-Only or XML.  The best way to incorporate
these exceptions in the spec is by having a modularized test suit.
[Categorization according to specification, being looked into; DD.] 
Yes, but maybe we should air some of the concerns on the dom-ts list and
try to come to agreement on the categorization [mb]
Suggestion for DOM Level 1:
o Core: HTML-Only With Exceptions
o Core: HTML-Only Without Exceptions
o Core: XML With Exceptions
o Core: XML Without Exceptions
o HTML (Exceptions are not used in HTML)
Dom Level 2: ???
Dom Level 3: ???
Would it be more useful to try to provide configurable exceptions -
maybe a set of entity def's that captures exceptions thrown by a
particular vendor, which are then used in the tests, or not check for
exceptions at all in cases where the method used is optional.  Doesn't
the spec indicate that an exception must be thrown? [mb]
The entity def approach could work, but it would require the XML file to
be edited/regenerated every time the script error message changes.  (I
don't know how often this might happen).  Also, the spec states "Some
languages and object systems do not support the concept of exceptions.
For such systems, error conditions may be indicated using native error
reporting mechanisms." So, the spec says that an error must be thrown,
but doesn't mandate that the error must be an exception. [jb]

Received on Monday, 9 April 2001 08:39:27 UTC