RE: Recap and action items

> [schema-specific]
> 1. We still haven't decided on whether to use roundtripping 
> to the schema or
> not during the transform. I personally prefer not doing this, 
> and putting
> any necessary information in the test description file, especially for
> information that is present in the DOM Spec.
> 
> I personally think we should use as much information from the spec as
> possible, and not require that roundtripping be made, either 
> to our DOM TS
> schema, or to the DOM spec, during transformation. Following 
> this argument,
> we would also have to explicitly declare return types, as was 
> done a few
> iterations ago.


You would need to have more than just returnType attributes,
you would also need to supply parameter ordering and
might need parameter types.

It seems a whole lot cleaner to me that the invariant DOM
definition be kept separate from the test definition.  Otherwise,
then we have to determine what subset of the DOM definition that
we need to replicate in the test definition and we have to
iterate if we don't put enough in.

As I have mentioned in the previous messages, we can
defer this decision with no adverse impact on test
authoring.

I think the last iteration is pretty stable, however I think it
would be premature to "finalize" it before we have attempted
to write the tests and transforms.

> One way is, as I see it, to go for required + "null". Making 
> C++ generation
> is perhaps the price we have to pay for being able to 
> generate most other
> bindings, except if there is a simpler, fits-all, solution. 
> In any case,
> Java and ECMA would have higher priority, as they are the official DOM
> bindings (as in the specs)

Passing an uninitialized variable of the appropriate type is
a simple fits-all solution.

> 
> 3. Categories/Groups on the SF pages: look good, we only need 
> to add a few
> categories as per the DOM TS Process document: submitted, 
> received, reviewed
> and stable, inappropriate

Those "categories" seem to be adequately represented by combinations
of existing status and resolution options:

Submitted: Status = Open
Received: Status = Pending
Reviewed and Stable: Resolution = Accepted,  Status = Closed
Inappropriate: Resolution = Rejected, Status = Closed

If we set up a SourceForge project for the Test Suite definition,
then it is easy to define a mailing list within the project and
set the tracker to send a message after any submission or 
comment.  However, I don't know if the membership of that list
would be substantially different enough from www-dom-ts to
warrant creating another list.

The preferred way of submitting a test would be to use "Submit New" in 
the tracker.  This would send an email to the mailing list with a URL
for the submitted test.  If a test was submitted via the www-dom-ts@w3.org
mailing list or a sourceforge mailing list, a team member could enter
the case in tracker or we can ask the submitter to use the tracker (
which might be cleaner since it would have presented them with the
intellectual property statement).

Once a test is submitted to the tracker, a CVS committer would perform
a sanity check on the submitted test (schema valid, 
tests against known implementations) and either raise issues 
with the submitter or add to CVS and make appropriate notation in the
Tracker.

Received on Tuesday, 5 June 2001 16:02:29 UTC