- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Tue, 5 Jun 2001 13:58:35 -0600
- To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
> [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