W3C home > Mailing lists > Public > www-svg@w3.org > December 2000

Variant of NIST DOM test suite with support for Adobe SVG Viewer and Xerces-COM

From: Curt Arnold <carnold@houston.rr.com>
Date: Thu, 14 Dec 2000 00:21:53 -0600
Message-ID: <001101c06596$26e956e0$f00ba8c0@houston.rr.com>
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:


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

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
Received on Thursday, 14 December 2000 01:21:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:49 UTC