Re: Comments on DOM Level 3 Core Nov-03 CR

On Wed, 2003-12-10 at 12:14, Andrew Clover wrote:
> CORE
> ====
> 
> Clarification: 1.3.3 paragraph 6 contains a caveat referring to DOM Level 2
> and 'a future version of the DOM', is this still relevant to DOM 3 given the
> ability of normalizeDocument to fix up unbound prefixes?

Yes, since you can still play with DOM Level 1 nodes, DOM Level 2 nodes,
and entities. DOM Level 3 does include a mechanism to fix namespace
prefixes but cannot fix that case. The paragraph has been updated to
match the current version of DOM however.

> Clarification: the text for Element.SetIdAttribute[NS|Node] is only accurate
> if the isId parameter holds true. The text should be amended to reflect the
> possibility of un-isId-ifying attributes.

Fixed.

> Proposal: UserDataHandler.handle: "Any exceptions thrown inside a
> UserDataHandler will be ignored." Does this really mean that user code,
> when called-back, may throw any exception and it'll be silently caught and
> swallowed, rather than allowed to propagate to the caller? This strikes me as
> really bad news for debugging, especially in languages like Python where an
> Exception covers a multitude of sins (eg. KeyboardInterrupt, MemoryError,
> etc.); it is also a marked change from the existing callback arrangement of
> NodeFilter in DOM Level 2 Traversal. If the aim is merely to avoid having to
> declare interfaces that 'throws Throwable' in Java, couldn't this be left as
> an issue for the language bindings?

This behavior has been in the DOM since DOM Level 2. DOM Level 2 Events
does indicate, when using EventListener:
[[
Any exceptions thrown inside an EventListener will not stop propagation
of the event. It will continue processing any additional EventListener
in the described manner.
]]
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-flow-basic

The group decided to stick with the current status quo, i.e. no change
in the specification. True enough, ignoring exceptions can render your
implementation unstable, but the intent is to prevent DOM applications
to rely on behaviors resulting from an exception thrown in the handler.

> Editorial: Node.cloneNode: "[...] has no parent; (parentNode is null.) and no
> user data." - superfluous semicolon and period in parentheses.

Fixed.

> Editorial: DOMConfiguration parameter order has element-content-whitespace
> listed at the end. The intention was probably to list the parameters
> alphabetically.

Fixed.

> Error: Document.normalizeDocument refers to Document.xmlConfig, should
> be domConfig.

Fixed.

> Editorial: TypeInfo: "The TypeInfo interface represent a type" - 'represents'.

Fixed.

> Editorial: DOMConfiguration: 'canonical-form': "the DocumentType node is
> removed from the tree if any and superfluous namespace [...]" - sentence is
> tricky to parse, suggest "the DocumentType node (if any) is removed from the
> tree, and superfluous [...]".

Fixed.

> Proposal: the DOMConfiguration parameter 'canonical-form' is currently
> neither fish nor fowl: it has its own state (like most parameters), but is not
> directly readable as it encompasses other parameters (as with 'infoset'). It
> may be too late to change this now, but it would be nice if it could be made
> to behave like 'infoset', with no internal state of its own.

We made it a real parameter, with its own state. It still does set other
parameters when set to true but modifying those other parameters will
also unset canonical-form.
[[
Setting this parameter to true will also set the state of the parameters
listed below. Later changes to the state of one of those parameters will
revert "canonical-form" back to false. 
Parameters set to false: "entities", "normalize-characters",
"cdata-sections". 
Parameters set to true: "namespaces", "namespace-declarations",
"well-formed", "element-content-whitespace".
]]

This also matches the behavior of canonical-form and format-pretty-print
on the LSSerializer.

>  A few parameters
> would need to be added to control eg. attribute/namespace declaration order
> and removal, empty element short forms (which might be a useful option to have
> in its own right) and doctype removal (could repurpose LS's 'disallow-doctype'
> for that).

This is definitively too late to be added now.

Philippe

Received on Monday, 5 January 2004 15:01:34 UTC