Re: prototype DOM TS Level [1|2] [Core|HTML]

Robert Clary wrote:

> The use of a javascript file to generate the list of tests in the 
> selection page and in the new-alltests.html suite. This eliminates the 
> need for the *alltests.xml suite definitions and the 
> *alltests.xml->*alltests.html transformation but requires a different 
> transformation to create the javascript file. If this approach is 
> approved I would like to work with you to determine the best approach 
> for implementing it.

The alltests could be generated from a directory using Ant.  However, 
the original idea behind the test suite definitions was that tests would 
go through a review cycle and there could be tests in the directory that 
were submitted but not accepted.  alltests was going to contain all 
tests regardless of status and there would be other suites of accepted, 
provisional and rejected tests, however that never evolved.  The 
downside of moving a test to signify rejection was that any test results 
that used that URL would be broken.

> This javascript file and it's recorded tests, their files and 
> implementation attributes provides the ability to determine, test and 
> filter tests by content type and implementation attribute.

I think I would prefer a more declarative approach, maybe an array 
containing with elements like:

tests[tests.length] = { 			 
"characterdatainsertdatanomodificationallowederr",   // test name
	null,                       // content type
	{ "XML" }, { null },        // features name and versions
	{ "expandEntityReferences" }, { false } };  // impl attributes

The function suite() method could iterate through the array and add only 
the applicable tests to the suite.



> The use of warn to record when an implementation does not match the 
> implementation attribute requirements of a test or the implementation 
> attributes selected by the user. I think the trace facilities in JsUnit 
> can be put more to use in reporting more information regarding the tests 
> and their results.

The Java framework does not give any indication that non-applicable 
tests are omitted.  If you want to avoid the situation of a processor 
passing, for example, the L3 Load Save suite because it passed 0 of 0 
tests by return false to hasFeature("LS-Load", null), you can always 
have one unguarded test that checks the feature.  I think that listing 
page after page of inappropriate tests could be distracting.

> The addition of .xhtml versions of the XHTML data files and the use of 
> application/xhtml+xml content type for http based test scenarios.

I'll also application/xhtml+xml to the contentType enumeration in the 
schemas and DTDs.

> The iframe in main-loader.html is not used to load the data files in 
> native mode. In native mode, the data files are loaded via iframes which 
> are generated during the loading of the test via document.write. There 
> is no limit to the number of loaded documents using this approach. Your 
> use of the the variable name for each document allowed me to name each 
> iframe separately from the actual file name and removed the limitation I 
> originally had last year of having unique file names.
> 
> The issue I have with the xslt automatically creating the iframes is 
> that only the native loader requires iframes and they are not needed for 
> MSXML[3|4] or Adobe SVG implementations. I believe this is better 
> handled during load via document.write.

I avoided dynamically created the IFRAME's since I thought it was one 
less moving part and the cost of an unused IFRAME was negligable.

> 
> It seemed to me that, in the current version in CVS the older "Builder" 
> code is still in the file, but it appeared to have been orphaned and 
> replaced by the IFRAME loader which was limited to loading HTML in the 
> iframes.

When I migrated the previous code to JSUnit 1.3.3, I retrogressed in 
functionality and temporarily dropped support for the other loaders, but 
I expected to reimplement additional loaders as we added back 
functionality.  I prefer the loader classes over extensive use of switch 
statements to achieve the same thing.


> The issue I have with the hc_* tests is that they don't follow the 
> normal scheme and would make the determination of supported content 
> types for a file more complicated, but not impossible. They seemed to be 
> a "bit of a wart", and if possible I was hoping to not have to special 
> case the supported content type determination for files.

For XML processors, they are essentially redundant with the non hc_ (for 
HTML compatible) tests.  However, without them there is minimal coverage 
of L1 core behavior for HTML processors.

Received on Saturday, 8 March 2003 01:30:45 UTC