RE: [xsl] Marshalling data (function parameters) into XSLT

["Michael Kay" <mike@xxxxxxxxxxxx>]

If the data is to be manipulated within the XSLT code, then it will have to
be converted from Java objects into XSLT objects at some stage. This
conversion can be done:

(a) explicitly in the calling application

(b) implicitly by the engine when parameters are passed, e.g. a Java int[]
array might be implicitly converted into an XPath xs:integer* list

(c) explicitly by calling extension functions within the stylesheet

Alternatively you might be able to avoid conversion, by using extension
functions as accessors to use the native methods of the Java object. (This
doesn't convert the original Java object, but it does convert the results of
its accessor methods.)

What is "efficient", of course, depends very much on the processor and on
the detail of what you are doing.

Michael Kay
http://www.saxonica.com/

> -----Original Message-----
> From: Justin Johansson [mailto:procode@xxxxxxxxxxx] 
> Sent: 25 September 2008 16:24
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] Marshalling data (function parameters) into XSLT
> 
> Hello XSLT List,
> 
> Given a scenario of using XSLT as a generic functional 
> computation engine, (and thereby invoking an XSLT transform 
> to implement the internals of a function, say, in the same 
> way as one might use the Java Native Interface (JNI) to 
> implement a function in C++) ...
> 
> What is the most efficient was to marshall external data into 
> the transform engine as "parameters to the XSLT-implemented function"?
> 
> Me thinks there are only two ways and please correct me if I 
> am wrong :-
> 
> 1) Serialize the function parameters into an XML formatted 
> character stream and feed this into the transform as the 
> source document
> 2) Pass the parameters into the transform via 
> Transform.setParameter (perhaps using an empty source 
> document to satisfy the XSLT Transformer need for a source document)
> 
> There is an obvious overhead in serializing using (1) if the 
> parameters already exist as native Java types.
> 
> Using (2) requires that the external (Java) driver can supply 
> data types directly to Transform.setParameter, and this 
> sounds like a more efficient way (to save the serializing 
> overhead of 1).
> 
> To reduce the assumptions that this question might pose, 
> let's assume a use case in the first instance,
> 
> Use case A:
> 	Use XSLT to implement a simple arithmetic addition of 
> two integers predisposed as Java int's.
> 
> Use case B:
> 	Use XSLT to implement a reduce (or fold), in functional 
> parlance, a sequence of values predisposed as, say, a Java 
> Vector<double>.
> 
> Thanks for the list's consideration of my question,
> 
> Justin Johansson