[XERCESJ-948] Reporting of DOMLocator.relatedNode

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.6.2
• Fix Version/s: 2.6.2
• Component/s: DOM (Level 3 Core)
• Assignee: Michael Glavassevich
• Reporter: Naela Nissar
• Created: 20/Apr/04 21:04
• Updated: 23/Apr/04 15:39
• Resolved: 22/Apr/04 20:43

Description

DOMNormalizer and DOMSerializerImpl make use of the method reportDOMError to report a DOMError to the error handler. This method has a relatedNode parameter in addition to being passed a DOMLocator object.

Currently, W3C DOM test documentnormalizedocument07 is failing because normalizeNode calls isCDataWF, sending the nodeValue (containing "]]>") as a string, but the isCDataWF method does not receive the actual CDATA node as a parameter. isCDataWF subsequently calls reportDOMError passing null for the value of the relatedNode parameter, instead of the expected problem CDATA node.

In the proposed patch, reportDOMError no longer takes relatedNode as a parameter, as this should be available in the Locator passed to it. The actual setting of relatedNode takes place in normalizeNode (in DOMNormalizer) and verify (in DOMSerializeImpl) above the switch statement. In a few instances, (such as when invalid characters are present in an attribute name), the value of relatedNode must be explicitly overridden to the value of a specific node. Not sure if this is the best way to handle things, since Locator data members would have to stay public.

Aside, I think it should still be okay for reportDOMError to set the value of relatedData to that of relatedNode, as the spec states that "When called, DOMError.relatedData will contain the closest node to where the error occurred" [1], although I know elsewhere it says relatedData is of type DOMObject

[1]http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#parameter-error-handler