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/23 19:50:53 UTC

[jira] Closed: (XERCESJ-920) reporting of DOMError.relatedData when cdata sections are split

Message:

   The following issue has been closed.

   Resolver: Michael Glavassevich
       Date: Fri, 23 Apr 2004 10:48 AM

Closed as per state in Bugzilla.
---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/XERCESJ-920

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: XERCESJ-920
    Summary: reporting of DOMError.relatedData when cdata sections are split
       Type: Bug

     Status: Closed
 Resolution: FIXED

    Project: Xerces2-J
 Components: 
             DOM
   Versions:
             2.6.2

   Assignee: Michael Glavassevich
   Reporter: Naela Nissar

    Created: Thu, 18 Mar 2004 10:40 PM
    Updated: Fri, 23 Apr 2004 10:48 AM
Environment: Operating System: Other
Platform: Other

Description:
DOMError.relatedData is not being reported anywhere in DOMNormalizer during 
reporting of errors (reportDOMError).  DOM L3 Core spec states that relatedData 
store 'the related DOMError.type dependent data if any'.  

Spec specificially states that when 'split-cdata-sections' is true 'a 
SEVERITY_WARNING with type "cdata-sections-splitted" is generated and the first 
CDATASection node in document order resulting from the split is returned by 
relatedData'. Under the description of the 'error-handler' parameter: 'When 
called, DOMError.relatedData will contain the closest node to where the error 
occurred. If the implementation is unable to determine this node, 
DOMError.relatedData will contain the Document node'  [1]

Currently, when an error is detected, reportDOMError is called and passes a 
node that relatedNode is set to.  The proposed patch involves setting the value 
of DOMError.relatedData inside reportDOMError to this same node value (don't 
know if that's right - but currently, DOMLocatorImpl constructors set 
relatedNode equal to relatedData). Also, in normalizeNode when a cdata section 
containing ']]>' is split, we send the second node resulting from the split to 
reportDOMError - not sure if it matters for value of relatedNode, but for 
relatedData, spec says it must be the first node from the split.  (Failing DOM 
L3 Core test documentnormalizedocument06 as a result)

With this patch, in the event that relatedData is passed the value of null, I 
couldn't find a way to allow relatedData to then take on the value of the 
document node [1] within the reportDOMError method without adding addit'l 
parameters.   Didn't think it would be good to write a new method to 
exclusively deal with relatedData either... 

[1]http://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/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