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

Curt Arnold wrote:
> 
> Robert Clary wrote:
> 
>  > Rick,
>  >
>  > Are you running the version from CVS?
>  >
>  > I combined and compared our two different results and have attached 
> as combined-results.txt.
>  >
>  > I noticed that the signature of assertURIEquals in DOMTestCase.js is:
>  >
>  > 
> assertURIEquals(assertID,scheme,path,host,file,query,fragment,isAbsolute,actual) 
> 
>  >
>  > and the call in my HTMLAnchorElement04.html is
>  >
>  > 
> assertURIEquals("hrefLink",null,null,null,"submit.gif",null,null,null,null,vhref); 
> 
> 
> 
> The DOMTestCase.js in CVS has ten parameters, one more (name) than in 
> your DOMTestCase.js, which is consistent with the transforms and 
> generated code.  The "name" attribute on assertURI was added sometime 
> before the last modification of HTMLDocument04.xml on 30 June 2002.
> 

Ah, thanks. Sticky tag strikes again. :-) I have updated the version I 
am using to match the 1.17 version in DOMTestCase.js and will post a new 
version and report the results shortly.

> I won't have any time to fully digest this till the weekend, but here 
> are a few quick comments/questions.
> 
> Is the essential innovation the use of the query string used to launch 
> JsUnit to configure the test framework?  Are there any other novel aspects?
> 

The query string is one of the basic ingredients which supports 
implementation choice, content type choice, implementation attribute 
choice and test choice but there are others as well.

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.

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.

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 addition of .xhtml versions of the XHTML data files and the use of 
application/xhtml+xml content type for http based test scenarios.

> Would there be any issues using a select box instead of radio buttons to 
> select the suite or test to run?
> 

None what so ever. This is just a prototype to show the basic 
functionality. I am open to whatever changes in the UI are desired. The 
list of tests is generated via a javascript document.write loop over the 
test data structures contained in the javascript file and is easily 
modified.

In particular I think more work in implementation attribute definition, 
selection and matching will be required. The approach I used in the 
prototype was simply to illustrate it's potential.

> The recently generated tests have had an <iframe> element in the test 
> html file for each document loaded by the test.  As far as I can tell, 
> your "native" loading uses the one iframe in main-loader.html and would 
> not support tests that use multiple documents such as 
> elementwrongdocumenterr.  Is there an issue with distinct <iframe>'s in 
> the test document?
> 

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.

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.


> You mentioned the hc_* variant tests.  These were added after first 
> release of DOM L1 Core to provide some coverage of the Core for HTML 
> processors since the original NIST tests required XML documents.  The 
> tests are a direct transliteration of the NIST types making tag and 
> attribute name substitutions to make the test documents valid (but 
> non-sensical) XHTML and HTML.  XML processors show the same results with 
> these translated tests as with the original tests.  However, there has 
> not been a thorough review by the team of test failures by XHTML or HTML 
> processors.  There are at least 4 hc_* tests that attempt to create 
> elements that have not been changed to use HTML tag names which I'll try 
> to change in the next few days.
> 

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.