DOM TSML 0.9

From: Dimitris Dimitriadis (dimitris.dimitriadis@improve.se)
Date: Mon, May 14 2001

  • Next message: Arnold, Curt: "RE: DOM TSML 0.9" 

    Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A63FC@VXOIMP1>
From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
Date: Mon, 14 May 2001 19:43:19 +0200
Subject: DOM TSML 0.9


Attached please find the slightly reworked NIST DTD with the following
changes, as well as a _very_ simplistic XML document showing what it is we
want to do:

1. Element TestData added and defined
2. Element Load added and defined (content is pointer to file location) 
3. Element Assertion added and defined
    Attribute Type to indicate type of assertion made (as in Junit, Same
will not be use
    since DOM does not test sameness of objects)
    Actual assertion content given as the text value of the Assertion
element
4. Element test can contain multiple assertions, to be used instead of
expected_results
    Element test has new attribute SpecPointer with the pointer to the
relevant part of the
    specification  

This reflects the discussion that has been going on on the various topics. 

TestData allows for information about the author as per the DOM TS Process
document.
The Load element simplifies for the harness application to locate the file
as well as know what to do with entities and whitespace.
Assertion could be used instead of expected_results

Allow for a day or so for sending the rewritten XSLT that will generate a
particular binding as well as the more comprehensive XML document, similar
to the one previous sent to the list, with the new tag-set introduced.

Repsect has been paid to the fact that tests will most certainly be
developed in some different framework, but submitted in this vocabulary. We
believe importing to and exporting from this format is pretty
straightforward.

Also please bear in mind that the most crucial aspect of the DTD is the
functionality, it will certainly need to be rewritten in order to enhance
readability (but those changes will be purely cosmetic), eg. concerning use
of caps, capitalization, naming convention and so forth. 

Also, it could be an idea to divide the DTD into smaller modules, one for
the core functionality and one for each particular language (with their
respective entity declarations).

We've also thought along the lines of JXUnit, but since we do not want to
favour any language over another, we've decided to propose that we go along
the lines laid out in the attached DTD and just make sure we have the
possibility of exporting to that framework (among others).

Mary, could you please check on the definition of type? I've defined it as
content:ANY in this version of the DTD, please advise.

We would also need to check the programming constructs as they seem to be
very complexely nested.

You are encouraged to divide various topics for discussion that will most
certainly come up into separate threads.

So, ladies and gentlemen, the floor is yours. Any comments/ideas/criticism
highly appreciated.

Kind regards,

/Dimitris

 <<methods20010514.dtd>>  <<test.xml>>