W3C home > Mailing lists > Public > www-dom-ts@w3.org > May 2001

RE: DOM TSML 0.9

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Mon, 14 May 2001 12:48:32 -0600
Message-ID: <B2C1451A181BD411B88A00E018C1C19C08AC4E@thor.aeathtl.com>
To: "'Dimitris Dimitriadis'" <dimitris.dimitriadis@improve.se>
Cc: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
I guess I have a couple of observations:

There seems to be no indication of how to set up the test, particularly what document should be loaded.  Of course, all the NIST tests load "staff.xml" but
that will be different when incorporating tests from difference sources.

A generic <CALL> element is being used to call methods defined in the DOM spec
and provides information that could potentially conflict with the DOM spec.  For
instance:

<CALL NAME="item" OBJECT_TYPE="NodeList" TYPE="Node" OBJECT="NONE" OBJECT_NUMBER="NONE" ASSIGNMENT="=" ASSIGNMENT_OBJECT_NUMBER="NONE" STATIC="NO" INFIX="NO">
  <parameters VALUE="0" TYPE="int" NUMBER="NONE" /> 
  </CALL>

In this call, the generic <CALL> element specifies that the return type of NodeList.item() is a Node and that the call takes one parameter.  Those are
already known from the DOM spec.  The test could be a lot cleaner, if the calls 
to known DOM properties or methods were represented by something like:

<test id="elementAssociatedAttribute">
	<!-- maybe should assign public ID's to the well known test cases?  -->
	<load href="staff.xml"/>
	<Document.getElementsByTagName tagName="address"/>
	<NodeList.item index="0"/>
	<Node.attributes/>
	<NamedNodeMap.getNamedItem name="domestic"/>
	<!--  what I think this test was really trying to check
                  but the NIST harness didn't support  -->
	<assertNotNull/>
	<Attr.specified/>
	<assertEquals value="true"/>
<test>

Since the tests can be identified by a URI, the metadata could be specified using RDF:

<RDF:about href="http://www.w3.org/dom1test#elementAssociatedAttribute>
	<dc:Author>Mary Brady</dc:Author>
	<dc:Description>...</dc:Description>
	...
</RDF:about>

The <TRY> element doesn't add information.  In this test, there is no
expectation of an exception so if any is encountered the test framework should
identify it as a failure.  In cases where there is an expectation of an
exception, the exception is expected on one particular call and that expectation
could be specified as part of the element for the call.

<CharacterData.substringData start="-1" end="10" exception="INDEX_SIZE_ERR"/>

The date is not compatible with the XML Schema datatypes "date" type.
Received on Monday, 14 May 2001 14:49:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:02 UTC