W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2003

Re: DOM Level 3 Core 20030609 comments

From: Philippe Le Hegaret <plh@w3.org>
Date: 24 Jul 2003 15:59:42 -0400
To: and@doxdesk.com
Cc: WWW DOM <www-dom@w3.org>
Message-Id: <1059076781.13646.313.camel@jfouffa.w3.org>

On Wed, 2003-06-11 at 18:55, Andrew Clover wrote:
> 1.2.3 (DOMUserData): the repeated wording "an application data" is rather
> odd; 'data' is of course plural.

correct.

> 1.3.6 (features): the new method of prepending a '+' to the feature name
> seems rather clumsy. If a Level 2 feature is updated to a Level 3 feature
> which can be non-castable, an application that wants the Level 2 feature
> and doesn't care about casting would have to call hasFeature twice to find
> out whether the feature can be supplied, once with "+"..."3.0" and once with
> "2.0".

The application would need to care anyway since, depending on the
result, it will have to access the object that implements the interface
using getFeature or by simple cast.

> Document.renameNode: it seems to be impossible to rename a node and end up
> with a non-namespace (Level 1) node. For orthogonality, shouldn't there be
> renameNode and renameNodeNS?

We discussed that and didn't find enough interest in having a
renameNode/renameNodeNS solution, so unless people start to express an
interest in having it, we won't do it. By the way, createDocument is
another exception to that orthogonality...

> Text.wholeText: by my reading of the definition of "logically adjacent text
> nodes", fooNode's wholeText should also give "barfoo". Is this a mistake?
> If not, why is fooNode adjacent to barNode but not vice versa? If wholeText
> is only supposed to look forwards, the spec should say so.

We updated the definition of logically adjacent text node as follow:
[[
Logically-adjacent text nodes are Text or CDATASection nodes that can be
visited sequentially in document order or in reversed document order
without entering, exiting, or passing over Element, Comment, or
ProcessingInstruction nodes.
]]

The example has been fixed accordingly (i.e. foo Node's wholeText
returns "barfoo").

> DOMError: still seems a bit vague. How exactly does a fatal error differ
> from an error?

A fatal error stops the processing, unlike an error. Unfortunately, we
did not consider your proposal (July 21), so we'll have to revisit this.

> Can an error handler be called for arbitrary DOM exceptions, or just
> the few circumstances defined here?

No. DOMExceptions are and stay exceptions. The relatedException is meant
to platform dependent ones, not DOMException. An example would be a
SecurityException or IOException when using DOMParser.

> Are parse errors in Load/Save
> going to cause DOMErrors?

[skipped in this message since it is regarding LS. will be tracked
separately]

>  What should DOMErrorHandlers do with unrecognised
> errors?

We certainly don't intent to define the required behaviors of
DOMErrorHandler for recognized or unrecognized errors. The unrecognized
error must be of one of the 3 severity levels but that's all. No changes
were done to the specification.


>  Are the "wf-..." errors warnings?

wf- error types (from the well-formed parameter) are:
- errors when generated after a call to normalizeDocument()
- fatal errors when generated by the DOMParser.

[skipping whitespace-in-element-content since we did not decide on it
yet]

> Interface CDATASection: "The DOMString attribute of the Text node..." -
> surely "The data attribute...".

correct.

As usual, let us know if you're satisfy or not with the resolutions,

Philippe
Received on Thursday, 24 July 2003 15:59:51 GMT

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