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

Recap and action items

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Tue, 5 Jun 2001 20:51:41 +0200
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A66E7@VXOIMP1>
To: www-dom-ts@w3.org
Back again after a national holiday

1. How far are we from finalizing the shema? We took the decision to move
against a unified framework but seem to still have som unresolved issues.
Can we deal with theses on the list or should I schedule another telcon?
[schema-specific comments below]

2. Given that we do indeed finalize this fairly soon, how long will it take
us to translate the existing tests? Mary?

3. We have Fred who's volounteered to write the documentation together with
me. I look forward to start doing this once we've finalized the schema.

4. NIST have agreed to provide us with the Java XSLT, so we need another one
for ECMA (those two will be the two that come along with the W3C DOM TS) and
any other XSLT provided. We already have Python (Fred).

5. We need to look into the resolution/status options for the submitted
tests, eg. by adding a pending option while a test is being investigated by
the DOM WG. Also we should decide on whether we submit through a mailig list
or SF.


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

---

2. We also need to decide on parameters (cut from one of Curt's mails):
I've had a change of heart on parameters.  In my manual schema, 
parameters that could be null were optional.  However that information is
not
in the xml source for the DOM spec and I don't think we want to introduce
any supplimentary information.  So if the parameter is required, how do
you specify that it is null.  One option would be to make allow "null" as
a special value in the argument.  Unfortunately, that could seriously 
complicate the code generation for C++.  It is a little more awkward
in the test, but it could greatly simplify the C++ code generation, if
null parameters are passed by passing in declared but uninitialized
variables, such as:

---

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)

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


[old action items, see
http://lists.w3.org/Archives/Public/www-dom-ts/2001May/0137.html]
1. Supply the schema with the construct parts (Curt/Mary/Dimitris) [being
looked into, we still have some issues to resolve]
2. Write the XSL for generating the Schema from the DOM XML specifications
(Curt has alreaddy done this, needs final polishing) [still awaits comments
and the decision on what to put in from the DOM spec]
5. Rewrite styelsheets for code generation (Java and ECMA primarily, others
welcome) (NIST for the Java one, ECMA open) [will be written as soon as the
schema is finalized]
6. Work on the details for test suite packaging (Curt, Dimitris?) [still
needs discussion]
7. Produce documentation (faq, help documentation, test production
descriptions) (Dimitris) [plus Fred]
8. Produce a test matrix (Mary/Dimitris) [pending]
9. Produce a list of semantic requirements (Mary, is connected to the test
matrix) [pending]


[done action items]
3. Start work on architecture for submitting/editing/approving tests (All,
Curt to submit a proposal) [done, as far as I can see, we just need to
clarify on whether we will also use a mailing list]
4. Look into an issue tracking system (there is no such colution within the
W3C) (Philippe/Jason) [done]

Have I forgotten anything?

Nearly there...

/Dimitris
Received on Tuesday, 5 June 2001 14:52:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:44 GMT