Re: Recap and action items

Comments inlined.

----- Original Message -----
From: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se>
To: "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>; <www-dom-ts@w3.org>
Sent: Wednesday, June 06, 2001 6:48 AM
Subject: 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.
>

[mb] We have already converted Node, Document, NamedNodeMap, CharacterData
without any problems, so I don't expect that we will have any additional
problems.

> > 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.
>

[mb] No problem with these categories, although I agree that we should have
the ability to distinguish between Received and "Pending on clarification
from WG"

> 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?
>

[mb] Another solution may be to run SharePoint here at NIST.  I haven't
used either solution, so I don't have strong feelings either way -- we just
need to be sure that all who want to participate can, and I think that can
happen with either solution.

> 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?
>
>

[mb] It seems to me that since this is an official W3C activity, that at
least the
submittal of tests should be via a w3c.org address.  Is there any way that
W3C could run a copy of SharePoint as well?

--Mary

Received on Wednesday, 6 June 2001 07:23:03 UTC