W3C home > Mailing lists > Public > www-dom-ts@w3.org > June 2001

Re: Recap and action items

From: Mary Brady <mbrady@nist.gov>
Date: Wed, 6 Jun 2001 07:27:36 -0400
Message-ID: <006d01c0ee7b$b0a1b670$0100a8c0@happy>
To: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se>, <www-dom-ts@w3.org>
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

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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:03 UTC