PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3503 *** shadow/3503 Fri Sep 7 12:27:25 2001 --- shadow/3503.tmp.345 Fri Sep 7 12:27:25 2001 *************** *** 0 **** --- 1,51 ---- + +============================================================================+ + | setIgnoringComments does not seem to work | + +----------------------------------------------------------------------------+ + | Bug #: 3503 Product: Xerces2-J | + | Status: NEW Version: 2.0.0 [beta 2] | + | Resolution: Platform: All | + | Severity: Normal OS/Version: All | + | Priority: Other Component: JAXP | + +----------------------------------------------------------------------------+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + The setIgnoringComments method of DocumentBuilderFactory does not seem to work! + + First, it is a little unclear exactly what this method is supposed to do. The + skimpy javadocs simply state: + "Specifies that the parser produced by this code will ignore comments" + + Well, what does "ignore comments" PRECISELY mean? + + I ASSUME that it means that whenever the parser hits a comment in the xml + document, it will ignore it as if it were never in the document. + + Consider this document fragment: + <someElement> + blah blah blah + <!-- comment, should be ignored --> + more blahs + </someElement> + + If my interpretation of "ignoring comments" is correct, then the <someElement> + tag should have precisely 1 child Node, a Text node to be specific. + + If you adopt a slightly looser interpretation of "ignore comments", then maybe + the parser might initially produce 2 child Text Nodes for <someElement>. In + this case, if you call on someElement's normalize method when working with the + DOM view of the document, it should coalesce the 2 child Text nodes into 1. + + In reality, I see neither of the above behaviors. Instead, all 3 child Nodes of + the original document are present in the DOM view (a Text Node, then Comment + Node, then the final Text Node). Here, I am using the default parser (i.e. + Xerces 2.0.0 beta 2). + + I assume that the above behavior is a bug. + + Regardless of whether or not it is a bug, the javadocs for the method need + considerable more fleshing out. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
