Re: Node.attributes readonly?

Dieter Köhler writes:
 > The 'attributes' property of the 'Node' interface is defined as being
 > readonly.  Does this apply only to the property as such or does it
 > extent into the functionality of the NamedNodeMap too, e.g. does

  I can't speak to the intent of the API designers, but I've always
seen it interpreted as "there is no set operation for 'attributes'".
This makes more sense to me; setting the list would be a fairly
expensive operation to make available through what may be
syntactically innocuous in some language bindings.  For example, this
would appear as

	someNode.attributes = someAttributesList

in Python; most Python programmers will consider this a "cheap"
operation.

 > calling myElement.attributes.setNamedItem (instead of using
 > myElement.setAttributeNode) raise a NO_MODIFICATION_ALLOWED_ERR
 > exception?

  Actually, I'm not sure how else to get ahold of the children of a
node in a general fashion, so this behavior would make the DOM nearly
read-only in practice.
  What I *would* like is a way to determine that a DOM object is
read-only; this should be exposed at the Node level (to see if a
particular Node is read-only, perhaps because it is a descendent of an
EntityReference), at the Document level (some particular Document is
read-only), or at the implementation level (the impl. only supports
read-only operation).  This would be useful at least for developing a
test suite to determine if an arbitrary implementation is operating as
expected.  There are enough nuances that a thorough test would need to
be conditionalized for that more introspective features would be
useful for.  A set of standard "feature" names would be useful for
this.  Another would be persistence beyond a process, as we're
starting to see more DOMs built on top of relational databases or other
non-transient data structures.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

Received on Sunday, 14 January 2001 10:32:02 UTC