- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Tue, 17 Apr 2001 13:52:11 -0600
- To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
tests nodeElementNodeAttributes and nodeCloneAttributesCopied, as
implemented, require a specific order to the NamedNodeMap
("domestic" followed by "street") that is contrary to the
DOM spec which explicitly states that NamedNodeMaps are not
maintained in any specific order
(http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1780488922)
tests TextParseIntoListOfElements, NodeEntityReferenceNodeType,
NodeEntityReferenceNodeName and NodeEntityReferenceNodeValue
all depend on the DOM parser not expanding
entity references. Expanding entity references is explicitly allowed as
an acceptible behavior in http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-11C98490
namednodemapChildNodeRange appeared to be designed to make sure that you could
call namedNodeMap.item(index) for values of index from 0 to length-1, but forgot
to ever actually call item(). In its current state it is just an elaborate
method of checking if namedNodeMap.getLength() returned 2.
In my JUnit variant of the NIST tests, I have written nodeElementNodeAttributes
and nodeCloneAttributesCopied so that a specific order is not dictated.
For NodeEntityReferenceNodeType and similar, if the parser is known to be
expanding entity references, the tests check for the expected text nodes instead.
For namednodemapChildNodeRange, I have added the call to namedNodeMap.item()
I will try to get the JUnit test suite up on SourceForge tonight.
Received on Tuesday, 17 April 2001 15:54:25 UTC