> a) It is assumed that the XSLT processor understands the DOM
>     returned by the invoked java method.

True. That's up to your XSLT processor's extension mechanism, since at 
this time extensions are not very precisely defined in the XSLT spec. Some 
processors, eg Xalan, explicitly list DOM nodes as one of the possible 
data types which can be returned from extensions, and promise to Do 
Something Appropriate with them. Others may not, in which case you should 
return the data another way (as a SAX source? as XML text?). Check your 
processor's documentation for details.

> b) It is assumed that the internal realization of the XPath is DOM 
>     based.

Nope. It just means the extension mechanism needs to be able to read the 
data out of the DOM node you've returned. It may operate directly on that 
node object... or it may walk the node's DOM tree and copy its content 
into a format which the processor would prefer to operate on... or it may 
do both or either depending on the context in which the returned value is 
used. Again, that's up to the processor -- XSLT 1.0 didn't describe what 
extension functions return or how it's interpreted, only how they're 
invoked.

Of course there's the separate question of whether the value returned to 
the variable is a treated as a Result Tree Fragment (which an XPath can be 
applied to) or as a list of nodes (which can't be directly processed as an 
XPath, and which would need to be converted via something like Xalan's 
nodeset() extension). Again, that's a question of how your processor 
implemented the case of an extension that returns a DOM node. I think this 
issue will mostly Go Away in XSLT 2.0, with the introduction of the 
Temporary Tree concept.

______________________________________
Joe Kesselman  / IBM Research

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list