Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XSLTransform setParameter

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: 'xom-interest' <xom-interest AT lists.ibiblio.org>, 'John Cowan' <jcowan AT reutershealth.com>
  • Subject: Re: [XOM-interest] XSLTransform setParameter
  • Date: Thu, 10 Feb 2005 11:17:03 -0800

On Feb 10, 2005, at 11:08 AM, Elliotte Harold wrote:

Michael Kay wrote:


If a random XSLT processor can cope with XOM nodes in its principal source
document, then it can cope with them in a secondary document supplied by
parameter. (And if it can't, then it can't). I don't see the difference.

Random XSLT processors can't cope with XOM nodes. XOM converts the nodes to SAX as it's passing them to the processor on input and then builds new nodes from SAX on output. (It's *very* useful that XSL Transformations, despite the name, never actually changes the input data. It always constructs a completely new tree.)

What would Saxon do if a SAXSource were passed as the value argument to Transformer's setParameter method?

What would Saxon do if a DOM Node, NodeList, or NodeIterator were passed as the argument to Transformer's setParameter method?


Saxon could simply look at the type of the parameter (via reflection to make it jars a soft dependency) and then wrap it into the desired saxon NodeWrapper type, e.g. the XOM NodeWrapper, the DOM NodeWrapper, etc. All of these implement TRAX Source and so fit easily into the saxon design. Similarly, if it's a list or iterator of some sort.

Wrapping rather than piping through SAX into saxon avoids SAX conversion overhead.





Archive powered by MHonArc 2.6.24.

Top of Page