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=4995>. 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=4995 Xalan doesn't work with non-document DOM source [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] ------- Additional Comments From [EMAIL PROTECTED] 2001-12-03 13:38 ------- I think this is working as designed, even if it is a change from previous versions. Think about it from the XPath rather than XSLT point of view for a moment. If you pass a DOM node into XPath as a starting point, you do want to be able to navigate upward to that node's ancestors and across to its siblings. XSLT is build on top of the XPath semantics, so I think it does make sense to say that even if you're styling a specific element (which XSLT itself doesn't define, please note), you're doing so in the context of the surrounding document tree. If that isn't what your application wants, I believe there's a relatively simple workaround: remove the DOM node from its parent before you pass it to us, or clone it and pass us the clone. We should then recognize it as being a separate tree. >There is no explicit mapping defined between XPath and DOM! The mapping is at the document level. The problem here is that you wanted to process only a portion of a document, _without_ breaking it off so it became its own document. The DOM Working Group is experimenting with its own version of an XPath API. One of the items on my own work list is to consider how well it maps to and from the TrAX processing model. What they do may influence what we should do... or vice versa.
