DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22562>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22562 Behaviour of DOMSource(Node) with XSLTC does not match description Summary: Behaviour of DOMSource(Node) with XSLTC does not match description Product: XalanJ2 Version: CurrentCVS Platform: Alpha OS/Version: All Status: NEW Severity: Normal Priority: Other Component: org.apache.xalan.xsltc AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The description of the DOMSource(Node) constructor in the JAXP 1.2 Specification reads as follows: public DOMSource(org.w3c.dom.Node n) Create a new input source with a DOM node. The operation will be applied to the subtree rooted at this node. In XSLT, a “/” pattern still means the root of the tree (not the subtree), and the evaluation of global variables and parameters is done from the root node also. That seems to imply that, given a document like the following, if the Node passed to the DOMSource constructor is the element node named "inner", the process of building the result tree should begin with the "inner" element, but that the document node in the XPath data model should correspond to the DOM's Document node, and presumably that the "doc" element node should be part of the input tree as well. <doc><inner><innermost/></inner></doc> XSLTC seems to begin processing at the root node rather than at the "inner" element node. See bug 22559 for corresponding bug in Xalan-Java Interpretive, and test case. Following is the output produced by XSLTC with that test: <?xml version="1.0" encoding="UTF-8"?> <matched-root> <matched-element name="inner"> <ancestor name=""/> <root/> <variable-value>inner</variable-value> </matched-element></matched-root>
