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

Curt Arnold wrote:
> 
> 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.
> 

Ok. I understand that alltests.xml should stay. The output should 
instead be the reusable javascript file containing the tests information 
rather than the current *alltests.html suites.

>> 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.
> 
> 
> 

Whether declarative or procedural it should be easy to read and to use. 
If declarative is desired then an initializer such as:

tests[tests.length] = {
    name: 'characterdatainsertdatanomodificationallowederr',
    doc: 'staff',
    implementationAttributes: { expandEntityReferences: 'false' },
    validating: 'false'
    };

is preferred due to it's readability and ease of use. I prefer a 
constructor and either procedural initialization or initialization by 
the constructor over an array based initializer list for several reasons:

1. it is more readable

2. it is more usable in the code, e.g.

    objectName.propertyName == value

    rather than

    nameArray[indexValue] == valueArray[indexValue]

3. it provides a definitely initialized object with which to work.

>> 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.
> 

I think that the test suite should allow the user to select the level of 
information that they desire if it can be supported. I believe use of 
warn or info or the other levels of trace in JsUnit can be appropriately 
used without providing "page after page" of warnings.

The appropriate choice of what is or is not in the base/default set of 
tests and which do not rely upon optional parser features can reduce the 
warnings except in the case where the user wishes to investigate the use 
of the additional features.

>> 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 also forced loads of unnecessary documents, caused 404's in web logs, 
and was restricted to choosing the mime type at build time if I recall 
correctly.

>>
>> 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.
> 

In the version I proposed in May 2002, I retained the use of builder 
classes although for the most part they were skeletons compared to the 
original implementation dependent classes which were in use at the time.

I didn't use build classes in this prototype since only a limited IFRAME 
builder was used in the CVS version and it was used in such a way that 
hard wired it's use into the tests.

Currently, the only relevant switches are the two 
DOMTS_USER_IMPLEMENTATION switches controlled by the user. One of which 
is used to initiate the creation of the objects which will load the test 
documents and the other to control IE specific features only. This isn't 
Object Oriented but is easily maintainable and extendible.

I have no objection to using builder classes however think we should 
make certain that:

1. user choice guides the selection of features used, not the builder

2. using builders should not make it difficult to add new
    implementations.

3. builders should only be used to make implementing the tests easier
    but not to hide results due to implementation differences in the
    browsers being tested.
> 
>> 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.
> 

Ok.