Re: Read-only and removeChild/replaceChild

>First, I wanted to verify that the read-only attribute of a Node is
>implementation-specific as of DOM Level 2

DOM Level 1, and Level 2, have two specific cases in which nodes will be
read-only: when they're  Entity or EntityReference nodes or are descendents
of one of these. (It's a bit hard to find this when casually searching the
DOM spec, I admit, since the term "readonly" is also an IDL keyword.
Perhaps we should have distinguished read-only nodes and readonly IDL
attributes, or used "immutable" or some other term. It's probably a bit
late to change it now.)

But we don't explicitly say that these are the only ways a node may become
readonly. Some implementations do provide other mechanisms -- some DOMs are
entirely read-only -- and while we haven't exactly blessed them we haven't
explicitly forbidden them either.

There has certainly been interest in the DOM working group in the
possibility of making specific nodes or subtrees read-only on demand (and
possibly in restoring mutability later), and there's been an active request
from the XSLT community for a clearly defined "read-only DOM" (since they
don't want to let user-written extensions change the source document while
a stylesheet is running)... but we haven't yet reached consensus on whether
this is a subset or a mode and exactly how it should behave, It's logged as
an Open Issue to be reconsidered at a later date.

>Secondly, I'm wondering about Node.removeChild. DOM2-Core specifies that
>NO_MODIFICATION_ALLOWED_ERR be raised if "this node is read only." We can
>assume that "this" refers to the parent of the child being removed. But
what
>about the child itself?

We explicitly allow a readonly node to be removed/reparented, _IF_ its
parent is not readonly. In particular: EntityReference nodes are explicitly
readonly (see above), but EntityReferences may be inserted and removed
freely. Their informational content is immutable; their context is not.

>For that matter, when a child is removed or replaced, what is supposed to
>happen to it's Node.ownerDocument?

See http://www.w3.org/DOM/faq.html#ownerdoc.

(The proposed DOM Level 3 adoptNode() method would alter this statement
slightly... but only when that method is explictly invoked, and only in
specific situations where the DOM implementation knows it can get away with
changing the node's ownerDocument.)

______________________________________
Joe Kesselman  / IBM Research

Received on Tuesday, 3 July 2001 20:14:18 UTC