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(_at_)adam(_dot_)com(_dot_)au]
Sent: 25 September 2008 16:24
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--