SV: Recap and action items

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