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

Re: Request for clarification

From: Martijn Pieters <mj@digicool.com>
Date: Fri, 16 Mar 2001 21:11:13 +0100
To: Mary Brady <mbrady@nist.gov>
Cc: www-dom-ts@w3.org
Message-ID: <20010316211113.C10676@zopatista.com>
> 1)  The setPrefix() method will throw a  NAMESPACE_ERR DOMException if
> the specified prefix is  malformed.  The same method will also throw an
> INVALID_CHARACTER_ERR if the specified prefix contains an illegal
> character.   What is the difference between a malformed prefix and a
> prefix with an invalid character? How are they distinguished?

We ran into the same question. On the WWW-DOM list it was answered as

- A qualfied name (QN) is malformed, if you cannot determine if it has a
  prefix, or where the prefix ends and the local name starts. Thus, a QN
  is malformed if it has:

    - more than one colon (:).

    - A colon at the start or at the end of the QN.

- A prefix is malformed if it contains a colon.

So in both these cases a NAMESPACE_ERR is appropriate. In all other cases
(where the QN or prefix doesn't match the XML Name production) a

> 2) The setPrefix() method will throw a NO_MODIFICATION_ALLOWED_ERR if
> this node is readonly.  How do you determine if a node is readonly or
> not?  Is there a way to specify a node as readonly?  As it turns out, we
> had problems converting our read only tests to Java and do not have any
> tests in this area.  Can anyone suggest a test scenario that will give
> us a read-only node that we can then manipulate?

Entity and EntityReference Node subtrees are read-only. However, you
cannot create Entity Nodes with the DOM Level 2 API alone.

In our DOM level 2 tests for Python DOM implementations the API asks for a
parse method to be passed in, next to the DOMIMplementation to be tested.
This method is expected to accept an arbitrary XML document (stored in a
string) and return a DOM tree built with the DOMImplementation that is

With the help of this method our tests *can* create Entity Nodes, and thus
execute tests on read-only Node types. We simply pass in a document that
defines an interal DTD which in turn defines an entity.

We test individual attributes on their read-only state by trying to change
them, expecting an exception to be raised. We also test for all situations
where a NO_MODIFICATION_ERR should be raised, for example when trying to
append a Node that itself is a child of a read-only node. There are no
other ways of determining wether or not a Node is read-only.

Martijn Pieters
| Software Engineer  mailto:mj@digicool.com
| Digital Creations  http://www.digicool.com/
| Creators of Zope   http://www.zope.org/
Received on Friday, 16 March 2001 15:11:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:11 UTC