DOM TS Telephone Conference 29/5/01

Present: Curt Arnold, Mary Brady, Jason Brittsan, Philippe Le Hégaret, Dimitris Dimitriadis, Jeroen van Rotterdam

Added agenda items: generate TS ML schema from the xml source for the DOM specifications

ACTION ITEM: will be looked into by Curt and Dimitris in the next few days

Agenda

1. Decision to be taken on whether we move toward one schema or keep two separate.

Curt: intends to move toward unity. some issues should be resolved. representing the interface that introduces a method. when you need to disambiguate, use an interface attribute. only in ambigous cases. in the current dtd you always have to specify the interface. in the current dtd you have no order of parameters. also when you have propos with two different return types (target attr for example). one motivation for using schema is to get that info from schema into the transformation.

Mary: frameworks not unified, just converging. we haven't reached unity yet. still think the schema is different than the dtd. language constructs not put in to the dtd sent to the list deliberately. to be put in later.

Dimitris: really want to see one framework to minimize effort put in

Curt: more comfortable with schema, therefore developing in schema (personal preference). we need access to info not present in the dtd. when you process an element that has milputiple parameters, you have no constraints on how they should appear; in the transform you would need to know this.

Mary: we could enforce this by moving away from attribute to element form. this was done in the first dtd.

Curt: we could get some of this info from the dom xml sources

Philippe: what is the advantage of schema instead of dtd?

Curt: additional constraint checking. peripheral issues on validation. expect to have both a schema and a dtd.

Philippe: again, are we going to validate every time we receive a test?

Mary: if we have both, we need to have two style sheets.

Curt: no, we just validate the same instance documents against different scheams. have used the november draft namespace. also valid if you use a more current namespace. there is also an online validator at w3c.

Jeroen: waste of time to continue on dtd, should go for schema

ALL: go for schema, produce dtd later ([mb]: will lose information). keep the IDL-ish naming conventions, boil both existing frameworks down to this set, extend with construct parts, metadata and packaging/suite defs.

Mary: as long as we don't lose information in transforming schema to dtd (wants functional equivalence, can obviously not have same degree of constraint checking)

2. Schema design: IDL interfaces instead of entities. DONE

Curt: specify an attribute in case of ambiguity, could be represented as a fixed attribute. known method names can be used to infer what interface they belong to.

PENDING on how complex the transformation becomes. will be looked into in the next few days.

3. Finalize the construct part of the schema

Will be done once the schema gets finalized. Add a few days to that

4. Finalize the schema(s)

XML source made available to the list (ACTION: Philippe), Mary, Curt and Dimitris. Should be done by Thursday May 31

5. Start working on architecture for submitting (CVS? What kind of issue tracking system? Bugzilla? Feedback from W3C needed)

Philippe: w3c system team is to install a bugzilla system, not ready yet. no date on when this can be done for the moment. recommends to find a place to develop the test suite. there is a cvs public server that uses ssh to access. no problem to use it. one alternative is to use w3c repository and ssh, another is to look at another proposal.

Curt: so a test gets submitted thorugh the list,is put on the w3c cvs by the moderator, people who want to look at the test can download the test with anonymous cvs?

Philippe: yes. we have a problem with bug-tracking system, however. no such solution to that within the w3c.

Curt: has played around with sharepoint. if microsoft wants to discuss hosting. similar to document managmemet sys, can have discussions on particular tests.

Jason: we can look into that

Mary: we have an nt and a solaris outside the firewall, can ask. not straightforward with nt though

Philippe: not a solution to have the submission area totally public, because you still need to check out tests and check them in at another places (as in submitted tests to checked tests)

Mary: does the w3c have anonymous ftp?

ACTION on Philippe to investigate.

6. (Re)write stylesheets for the two default bindings: ECMA and JAVA, others are welcome (pending on final version of DOM TSML)

PENDING on schema update

7. Produce reference documents to simplify test authoring. (see action on DD below)

PENDING on schema and framework being fixed

8. Motivation and Visibility

Curt: feels situation is better now.

Philippe, [dd]: dom ts separate from dom wg. wg members free to joing ts.

Other issues that have been raised and need to be discussed:

9. Metadata (feedback from RDF/EARL)

Curt, Philippe, Dimitris: RDF adds too much complexity to the ts ml

Curt: current description element allows rdf: element, does not presuppose them. we could let people include rdf: information

Mary, Philippe: hard enough to make people document their tests, so we should keep the metadata framework at reasonable levels

Dimitris: will receive word from WAI/EARL on why we should propose to implementors that they incorporate EARL into the harnesses they will write to run the tests

10. Suite design (should it include the XML test description? Point to files?)

Dimitris: both inlined tests and linked tests?

Curt: keeping tests distinct as document simplifies maintenance. each test and each asserting should be identifiable by a uri. if we decide to only accept 5 of 20 tests submitted, we can point to particular submitted tests. this defines suite in terms of external links, package is a construct for putting tests into one file. building the suite is made by identifying via the uri. packaging is a packaging concept, suite is a collection/decision type process.

Philippe: we may want to introduce tools to simplify packaging. agrees with curt, with separate files, and a description of the suite

Mary: lots of overhead introduced for NIST but it's a one time job. could be introduced into the test matrix

Curt: take a shot at package/suite/transform

ACTION: Curt to come back to the mailing list with ideas on packaging/suite/transform)

11. Test dependencies

Curt: if you have failure on one interface, you have many errors representing the same fundamental error. as a developer, which one do you trace down first?

Jason: we don't need the kind of complexity introduced by the framework, would like to see isolated test cases with clearer outline

Mary: on some of the tests you could perhaps use implementation conditions (hasFeature HTML) or whatever

Mary: haveFeature in the top of the tests can require, say, support for events. suite should provide info on what is needed to take the tests. events, exceptions and so on.

Jason: agrees

12. Compatibility with the various XUnit frameworks, including roundtripping

Curt: think we can do that. roundtripping not currently a huge issue. most testing will be done in binary form (java) then transmitted to xml format by developers

Mary: we may not want to lock us into a particular testing format. xunit doesn't seem to work under mozilla.

Curt: batik guys quite interested in the framework

All: the framework supports export/import vis. xUnit type frameworks (for the test representations themselves)

13. Coordination with XML Schema test development.

Curt, Dimitris: no replies yet.

Pending action items:

Test Matrix [Dimitris]

Dimitris: one test per test purpose. test matrix will contain tests that haven't been submitted.

Mary: could be brought in sync with the list of semantic requirements

Jason: recommends Cem Kaner's Testing computer software

Documentation [Dimitris]

List of Semantic requirements (and information to interested submitters on what tests we need) [Mary]