Re: setNodeValue tests

From DOM Level 1 Second edition (and L2 Core and L3 Core)
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-core.html#ID-F68
D080

"The value of this node, depending on its type; see the table above. When it
is defined to be null, setting it has no effect. "

(The original DOM L1 didn't have the "When it is defined to be null.." and I
didn't see the corresponding errata in the errata list, but its inclusion in
L1 Core Second Edition would imply that there was an errata.)

In the referenced table, Document, DocumentFragment, DocumentType, Element,
Entity, EntityReference and Notation are defined to be null.

Since NO_MODIFICATION_ALLOWED_ERR is mentioned as a possible exception when
the node is read-only, there is a ambiguity in the case where the nodeValue
is defined as null and the node type is readonly.

Document, DocumentFragment, and Element (except when a child of Entity or
EntityReference) nodes are clearly not readonly (and the corresponding tests
for these nodes were not an issue).

DocumentType Node (test nodeValue04):
http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-412266927

The sentence "The DOM Level 1 doesn't support editing DocumentType nodes."
(and similar in DOM L2) implies that a DocumentType node is not readonly by
nature, but only that DOM does not provide a mechanism to modify the
DocumentType.  It would apparently be acceptible for a implementation
specific interface to change the DocumentType node.  Since DocumentType does
not appear to be readonly, there is no conflict between the "defined as
null" clause and the NO_MODIFICATION_ALLOWED_ERR and test nodeValue04 seems
to be valid.

Notation Node (nodeValue08)

From http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-5431D1B9,
"The DOM Level 1 does not support editing Notation nodes; they are therefore
readonly."

This EXACT sentence appears also in DOM L2 and L3 Core.  It seems out of
place for the DOM L3 to say that Notation nodes are readonly since there is
no way of editing them in DOM L1.

However, there at least seems to be the potential for conflict between the
"when defined to be null" clause and the raises NO_MODIFICATION_ALLOWED_ERR.

Entity node (nodeentitysetnodevalue, nodeValue07):

DOM L2 explicitly stated that Entity nodes were readonly (DOM L1 explicitly
mentioned children of entity nodes but not the Entity node itself).

Entity Reference node (nodeValue03):

Same as Entity node.

Some other links:
http://lists.w3.org/Archives/Public/www-dom-ts/2002Feb/0142.html
http://www.geocrawler.com/archives/3/318/1999/7/50/2480234/
http://lists.w3.org/Archives/Public/www-dom/1999JulSep/0022.html
http://lists.w3.org/Archives/Public/www-dom-ts/2001Oct/0029.html

I had thought there had been a definitive resolution from the WG, but I
couldn't locate on in the mailing lists.

If it was intended for exceptions to be raised on Notation, Entity,
EntityReference and DocumentType then the phase "When it is defined to be
null, setting it has no effect" would only be true for 4 of the 8 node types
where nodeValue is defined to be null.  Since the authors of the DOM spec
should be aware that many of the nodeTypes that are defined to be null are
also read-only, I'd take that as a clear indication that they wanted the "no
effect" clause to supercede the read-only exception.

Some of these tests (the ones that aren't nodeValueXX) have existed in the
NIST test suite for some time and previous versions of Xerces-J and Crimson
successfully passed them.  It seems undesirable (even if allowed under the
recommendation) for Xerces-J to change its behavior on these cases.
However, a definitive opinion would have to come from the WG.


----- Original Message -----
From: <nddelima@ca.ibm.com>
To: <www-dom-ts@w3.org>
Sent: Thursday, February 14, 2002 4:10 PM
Subject: setNodeValue tests


> I downloaded and ran the DOM test suite against XercesJ2.0.0 ( a nightly
> snapshot about a day or two old) and noticed the following new test case
> failures...
>
> nodeentitysetnodevalue
> org.w3c.dom.DOMException: Entity nodes are read only
> at org.apache.xerces.dom.EntityImpl.setNodeValue(EntityImpl.java:331)
> at
>
org.w3c.domts.level1.core.nodeentitysetnodevalue.runTest(nodeentitysetnodeva
lue.java:65)
> at
org.w3c.domts.JUnitTestCaseAdapter.runTest(JUnitTestCaseAdapter.java:50)
>
> nodevalue03
> org.w3c.dom.DOMException: Entity Reference nodes are read only
> at
>
org.apache.xerces.dom.EntityReferenceImpl.setNodeValue(EntityReferenceImpl.j
ava:316)
> at org.w3c.domts.level1.core.nodevalue03.runTest(nodevalue03.java:56)
> at
org.w3c.domts.JUnitTestCaseAdapter.runTest(JUnitTestCaseAdapter.java:50)
>
> nodevalue04
> org.w3c.dom.DOMException: DocumentType nodes are read only
> at
>
org.apache.xerces.dom.DocumentTypeImpl.setNodeValue(DocumentTypeImpl.java:36
9)
> at org.w3c.domts.level1.core.nodevalue04.runTest(nodevalue04.java:56)
> at
org.w3c.domts.JUnitTestCaseAdapter.runTest(JUnitTestCaseAdapter.java:50)
>
> nodevalue07
> org.w3c.dom.DOMException: Entity nodes are read only
> at org.apache.xerces.dom.EntityImpl.setNodeValue(EntityImpl.java:331)
> at org.w3c.domts.level1.core.nodevalue07.runTest(nodevalue07.java:60)
> at
org.w3c.domts.JUnitTestCaseAdapter.runTest(JUnitTestCaseAdapter.java:50)
>
> nodevalue08
> org.w3c.dom.DOMException: Notation nodes are read only
> at org.apache.xerces.dom.NotationImpl.setNodeValue(NotationImpl.java:217)
> at org.w3c.domts.level1.core.nodevalue08.runTest(nodevalue08.java:60)
> at
org.w3c.domts.JUnitTestCaseAdapter.runTest(JUnitTestCaseAdapter.java:50)
>
> As per my understanding of DOM Level1 spec, the DocType, Notation, and
> descendants of Entity and EntityReference nodes are read only.  DOM Level
2
> goes further to state that Entity and EntityReference nodes and their
> descendants are readonly.  Calling Node.setNodeValue(...) on readonly
nodes
> should result in a NO_MODIFICATION_ALLOWED_ERROR which Xerces appears to
be
> doing.  So I'm not quite sure if these are valid failures.
>
>
> Thanks for all your effort and a great job with the test suite.
>
> Neil.
> IBM  - Toronto Lab,
> e-mail: nddelima@ca.ibm.com
>
>

Received on Thursday, 21 February 2002 02:16:51 UTC