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