The following issue has been updated:
Updater: Naela Nissar (mailto:[EMAIL PROTECTED])
Date: Tue, 20 Apr 2004 2:06 PM
Comment:
Proposed patch to DOMSerializerImpl and DOMNormalizer concerning the reporting of
relatedNode
Changes:
Attachment changed to relatedNodepatch.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/XERCESJ-948?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/XERCESJ-948
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XERCESJ-948
Summary: Reporting of DOMLocator.relatedNode
Type: Bug
Status: Unassigned
Priority: Minor
Project: Xerces2-J
Components:
DOM
Versions:
2.6.2
Assignee:
Reporter: Naela Nissar
Created: Tue, 20 Apr 2004 2:04 PM
Updated: Tue, 20 Apr 2004 2:06 PM
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
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
