Re: Minor comments for DOM Level 2 PR 20000927

Most of Susan's suggestions seem reasonable; assume I agree with any I
haven't commented upon.

[A grumble of my own: Is there any chance we could make the documents
entirely self-contained? My connection to the W3C's servers is running slow
today, and because we're referencing a few files off those servers (eg the
W3C logo), even my local copies of the DOM spec are delayed while the
network struggles with those references. Changing this would involve moving
those files into our own directory/zipfile....]


>Have you considered a cover sheet linking to all modules

The DOM group's home page might be able to serve that purpose, if the specs
pointed back to it. If we do a new "anchor" document instead, perhaps we
should factor the DOM's general introduction out of Core and up to this
level,


>it might help then to title each module as a "Module"
>rather than a "Specification"

They're intended to be Specifications in the W3C sense, to allow us to
update them individual in the future if that's appropriate. But I agree
that their abstracts and/or introductions should clearly state their
relationship to the DOM core, for the benefit of anyone who reads them out
of order.


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

Does HTML 4.01 change anything that the DOM would have to expose? If so,
then I think the answer really is that the HTML DOM was designed for HTML
4.0 and has not yet been updated. (That possibility is why we need to state
a specific version rather than saying "HTML 4".) If the changes are
harmless w/r/t the DOM, I agree that updating the reference is worth doing.


>In the Copyright Notices, can the dollar sign be removed
>from [$date-of-document] and [$date-of-software]?

I believe these will be replaced with real dates when we go to REC.


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

Looks like an improvement to me. "The Working Group considers" everything
in the spec to be worthwhile, after all.


>In Traversal, 1.1.2.3
>can not -> cannot

We've discussed this point previously.

As one of the editors of the Traversal chapter, I appreciate the suggestion
but I'm going to reject it. "Cannot" is a contraction (check the
dictionary) and as such has no advantage over the more commonly used
"can't". If anything, the fact that it uncommon (at least in my dialect of
English) makes it less readable than either of the alternatives.

Contractions are never mandatory, and in fact many writing guides
discourage them in formal communication. I prefer a somewhat conversational
tone, so I'm sure I haven't avoided them completely -- but I really don't
see any advantage to introducing this one.

Received on Monday, 9 October 2000 09:45:52 UTC