Re: DOM TSML 0.9

I've inlined my coments below.

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: "'Dimitris Dimitriadis'" <dimitris.dimitriadis@improve.se>
Cc: <www-dom-ts@w3.org>
Sent: Monday, May 14, 2001 2:48 PM
Subject: 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.

Yes, a pointer to the file to be loaded should be included.  This is a
problem for the NIST tests as well, as they all do not load "staff.xml".

>
> 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>
>

Although you see a variety of attributes associated with the call, many
of these are defaulted and are only required in special circumstances.
At first pass, the <CALL> element was quite simple.  As we stepped
through our tests, it became necessary to tweak this line for additional
functionality.  The following come to mind:

    * support for operating on a named parameter -- not necessarily
       the result of the previous call
    * type casting
    * Multiple parameters of the same type
    * Invoking a method with and without assignment

The test writer is only required to use the additional functionality when
necessary.
Otherwise, appropriate default values are supplied.  The snippet of test
code that
Curt supplied is after the expansion of attribute defaults and entities --
what the test
writer supplies in this case is the following:

<CALL NAME="&item;" OBJECT_TYPE="&nodeList;" TYPE="&node;" >
<parameters VALUE="0" TYPE="&int;"/>
</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>
>

This boils down to a matter of syntax and where what functionality should be
placed.  Even in this
scenario, with you deal with more complex tests, you are still going to have
to deal with multiple
parameters of the same type, operating on a named parameter, and invoking a
method with or
without assignment.  Type casting could probably be handled in the
transformation side --
since not all dom calls have the same name across bindings, this mapping to
a specific
binding will have to be handled somewhere -- are you proposing in the
transformation?

> 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>
>

What does this buy us?

> 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"/>

Yes, it could, but you are then dependent on a particular harness.   We were
trying to
keep the harness rather simplistic.  The key here would be to identify where
exceptions
could potentially occur and come up with the syntax to cover it.

So far in these comments, I see syntax issues -- are there any functional
issues that we
have missed?

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