Re: New EE variants of NoModificationAllowed.xml's, most tests now option safe

Didn't you have an element that could identify conditions under which the test should be 
run?  How about if we make the harness smart enough to accept as input test 
conditions, and only run the tests that are available for those conditions instead of 
running through the tests twice?  It seems as though I remember some other implementations 
that had somewhat different variants of whitespace -- in some cases, comments and 
"normal" whitespace were stripped, in others, only "normal" whitespace was 
stripped.  Given that these options are not well-defined, we could let the implementor 
using the tests provide the proper info.

--Mary
  ----- Original Message ----- 
  From: Curt Arnold 
  To: www-dom-ts@w3.org 
  Sent: Thursday, August 23, 2001 4:18 AM
  Subject: New EE variants of NoModificationAllowed.xml's, most tests now option safe


  Since expanding entities on load is an acceptible behavior, I've added siblings of all the *NoModificationAllowedErr tests with an EE suffix (for entity expansion) which tests the same behavior using created entity references instead of loaded entity references.

  I've made most of the tests safe for different parser settings.  Tests are most commonly affected by expandEntityReferences and ignoringElementContentWhitespace.  Some DOM are hardwired to a particular setting (Xerces-C always expands entity references, Batik ignores element content whitespace).  The harness runs the test suite twice, once with the default settings and then once with complementary settings.

  Tests that declare <implementationAttribute> immediately after the metadata element will modify the default DocumentBuilderFactory for the test pass to their needs.  So in the second pass when most tests are expanding entity references, ...NoModificationAllowedErr tests will not expand entity references but will keep all the other settings.