- From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
- Date: Wed, 6 Jun 2001 12:48:18 +0200
- To: "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>, "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
comments inlined -----Ursprungligt meddelande----- Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com] Skickat: den 5 juni 2001 21:59 Till: 'www-dom-ts@w3.org' Ämne: 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. [dd] OK, we'll keep the option open to lift in any experience we make when writing tests. > 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. [dd] OK, so, Required, with null as a default value? > > 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 [dd] No problem for me, it's just terminology. It could also be good idea to have a pending flag while the DOM WG considers a tests and its relation to the specification. 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. [dd] It actually may be different enough. We have to consider the case where someone ion a large organisation gets asked to simply submit tests without taking part in the process and development. If it's doable to work on a www-dom-ts-submissions@w3.org mailing list and we don't lose any vital functionality, I'd much prefer that. The DOM TS is, after all, a W3C thing, whcih on the other hand is publically developed. I think both aspects are reflected in the fact that we use SF for issue tracking. 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). [dd] See above, I think what you say is fine and well, but I wan the option open for submitting directly via mail (for both practical and historical reasons). So, what about both? 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. [dd] Here we need to keep in mind the Process Document that initiated the DOM TS activity, which states that the moderator for the TS (the DOM WG representative at present, hopefully more people) should change the status for the test once it has been reviewed, allowing for the possibility to take it to the DOM WG in case of confusion. A general question, though: How do we deal with the fact that the DOM TS will be published under the W3C document license? Which IPR statement is it people will be presented with when they use the SF platform?
Received on Wednesday, 6 June 2001 06:49:04 UTC