W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2000

Minor comments for DOM Level 2 PR 20000927

From: Susan Lesch <lesch@w3.org>
Date: Sat, 7 Oct 2000 19:42:42 -0700
Message-Id: <p05001900b6058d4fb84d@[204.210.31.147]>
To: www-dom@w3.org
Cc: w3t-comm@w3.org
Here are just a few comments for your DOM Level 2 Proposed
Recommendation [1,2,3,4,5,6] based on a quick read-through. Please feel
free to use or ignore them, as you see fit.

Have you considered a cover sheet linking to all modules, with updates
issued to this specification as a whole, when one module changes? It's
quite difficult to comprehend all the parts of the DOM when there are
modules, Levels, and versions. If it is impossible to unify each Level
under a cover sheet, it might help then to title each module as a "Module"
rather than a "Specification" (which leaves it to the reader to discover
later that they are reading a "module").

Globally, can references and links to HTML 4.0 be updated
to HTML 4.01 (or possibly be labeled simply "HTML 4")?

In the Copyright Notices, can the dollar sign be removed
from [$date-of-document] and [$date-of-software]? It catches
the reader's eye but carries no meaning that I could
understand except that it may be copied from W3C's license.

"ECMAScript" is one word (see ftp://ftp.ecma.ch/ecma-st/Ecma-262.pdf).
It appears as two words in each module in:
- TOC
- Expanded TOC
- ECMAScript Appendix heading
- ECMAScript Appendix par. 1
- Acknowledgements Appendix under Production Systems

In Core, Introduction, Compliance par. 1
level 2 -> Level 2

In Core 1.1.4, references to the Working Group and to "we"
could be stronger and perhaps easier to translate if reworded (see
http://lists.w3.org/Archives/Public/www-international/2000AprJun/0058.html).
For example:
     these two attributes must contain the same value, but the
     Working Group considers it worthwhile to support both,
     given the different constituencies the DOM API must
     satisfy.
becomes:
     these two attributes must contain the same value, but it
     is worthwhile to support both, given the different
     constituencies the DOM API must satisfy.

In Core 1.2, Interface Element, Attributes, tagName
There might be a stray comma in the example.

In Events 1.4, Interface Event, Methods, initEvent eventTypeArg
a new event type.. -> a new event type.

In Style, 2.3. CSS2 Extended Interface
The interface found within this section are not mandatory. ->
The interfaces found within this section are not mandatory.

In Traversal and Range, Abstract
     The two modules contains specialized interfaces dedicaced
     to traversing the document structure and identify a range
     in a document.
4 small changes:
     The two modules contain specialized interfaces dedicated
     to traversing the document structure and to identifying
     a range in a document.

In Traversal, 1.1.2.3
can not -> cannot

In Range, 2.5 par. 3
anboundary-point -> a boundary-point

[1] http://www.w3.org/TR/2000/PR-DOM-Level-2-Core-20000927/
[2] http://www.w3.org/TR/2000/PR-DOM-Level-2-Views-20000927/
[3] http://www.w3.org/TR/2000/PR-DOM-Level-2-Events-20000927/
[4] http://www.w3.org/TR/2000/PR-DOM-Level-2-HTML-20000927/
[5] http://www.w3.org/TR/2000/PR-DOM-Level-2-Style-20000927/
[6] http://www.w3.org/TR/2000/PR-DOM-Level-2-Traversal-Range-20000927/

Best wishes for your project,
-- 
Susan Lesch, W3C
mailto:lesch@w3.org
Received on Saturday, 7 October 2000 22:43:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:48 GMT