SV: DOM TSML 0.9

Hi Curt

Thanks for your quick response

This is of course a proposal, so things are being put to discussion. I'll
try to answer your questions below:

-----Ursprungligt meddelande-----
Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
Skickat: den 14 maj 2001 20:49
Till: 'Dimitris Dimitriadis'
Kopia: 'www-dom-ts@w3.org'
Ämne: RE: DOM TSML 0.9


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.

*** This will presumably be in the test file when it is submitted to the
test suite. Of course it will vary from implementation to implemetation, but
could be up to the harness to resolve.

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>

*** Sure, but I'm not sure this goes for all tests. In this case you're
right, but I presume there are others where your simplified version wouldn't
be enough. We could keep the more advanced version, clean it up a bit, and
make more elements optional to keep the size down.

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>

*** This is a very good point and I'd really like us to move along those
lines. Could you make some suggestions in document form? It doesn't add
functionality, but uses RDF, which in itself is a good thing (at least for
those of us who like it). 

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.

*** Perhaps it isn't well used in this particular test. Let me look at it
and get back to the list.

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

The date is not compatible with the XML Schema datatypes "date" type.

*** Again, thanks for your comments. I'll update the proposal. Do others
have any thoughts?

/Dimitris

Received on Tuesday, 15 May 2001 08:51:46 UTC