You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by ji...@apache.org on 2004/04/20 23:06:53 UTC
[jira] Updated: (XERCESJ-948) Reporting of DOMLocator.relatedNode

The following issue has been updated:

    Updater: Naela Nissar (mailto:nnissar@ca.ibm.com)
       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 "]]&gt;") 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: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org