- From: Curt Arnold <carnold@houston.rr.com>
- Date: Thu, 14 Dec 2000 00:21:53 -0600
- To: <svg-developers@egroups.com>
- Cc: <www-svg@w3.org>, <xmlconf-developer@lists.sourceforge.net>, <xerces-c-dev@xml.apache.org>
A modified version of the DOM Test Suite for ECMAScript (http://xw2k.sdct.itl.nist.gov/xml/dom-test-suite.html) is now available on the xmlconf project on SourceForge (http://xmlconf.sourceforge.net) under GNU license. This modified suite has been adapted to test Adobe's SVG Viewer, Xerces-COM and MSXML 3 in addition to the default XML parser for Internet Explorer 5. The tests must run within Microsoft Internet Explorer 5 or later. The test suite can either be run directly from the xmlconf site (http://xmlconf.sourceforge.net/dom1/ecmascript/index.html) or can be downloaded ro be run locally. Unfortunately, the SVG viewer test only runs locally at this time. There is currently a problem with file releases on SourceForge which is preventing issuing a release, however the files can downloaded from http://home.houston.rr.com/curta/dom1/dom1.tar.gz Alternatively, the dom1 module may be checked out of the xmlconf CVS using anonymous CVS. Once extracted, load ecmascript/index.html from Internet Explorer. General notes: There are HTML related tests that are not appropriate for XML-only products that have not been removed from the tests, however these are typically mention HTML in their description. The original NIST version depended on a decent number of MSXML-isms, most significantly that the XML declaration was represented as an ProcessingInstruction node. The PI tests have been rewritten to use a true PI added to the test files. Almost all tests that should raise exceptions fail (especially for non-MSXML implementations). The getCode function in util.js attempts to map either the exception.number (COM HRESULT) or exception.description back to the error codes described in the DOM spec. The current implementations are not satisfactory since they will often use the same number (HRESULT) or description for exceptions that should have distinct codes. I'd recommend that implementations define HRESULT like: HRESULT E_INDEX_SIZE_ERR = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_ITF, INDEX_SIZE_ERR); So that the DOM spec's codes can be easily extracted from the HRESULT. Several tests (for example, Core0009C) are fail in the same manner for all implementations suggesting a possible test problem (or at least a consistent misinterpretation of the spec by implementors) Notes on the Adobe SVG tests: The Adobe SVG Viewer's getSVGDocument method will throw an exception if the document element is not an svg element. Though this behavior is understandable, it makes it difficult to use standard XML tests against the viewer. The DOM test uses slightly modified test files (staff.svg instead of staff.xml) for the SVG viewer which results in a few spurious warnings (Core0013NO, Core0022NO, Core0049NO, Core0001D) about the document element tag name being svg and not staff. It would be beneficial (especially for XML conformance tests where changing the root elements on the test files is not practical), if there was a mechanism to get a IDOMDocument if an non-SVG file was loaded. IDOMDocumentType.notations returns a zero member collection for cases with notations resulting in failures for tests Core0012NO and Core0024NO Blank strings are returned in multiple tests were null should have been returned. Tests Core0001DI, Core0002DI, Core0025NO, Core0030NO, Core0033-Core0035NO, Core0064NO, Core0003D, Core0004D, Core0007D, Core0009D, Core0015D all appear to be legitimate errors. I haven't researched all the others. Please mail any comments, fixes or interest in participating to xmlconf-developer@lists.sourceforge.net.
Received on Thursday, 14 December 2000 01:21:26 UTC