W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2001

Re: Node.attributes readonly?

From: Fred L. Drake, Jr. <fdrake@acm.org>
Date: Sun, 14 Jan 2001 10:27:04 -0500 (EST)
Message-ID: <14945.50504.500386.925448@cj42289-a.reston1.va.home.com>
To: Dieter Köhler <dieter.koehler@ppp.uni-bamberg.de>
Cc: "www-dom@w3.org" <www-dom@w3.org>

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 GMT

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