In an integrated extension function, you can get the namespace
context at the point where the function is called during the call of
ExtensionFunctionCall.supplyStaticContext(). The StaticContext
object passed on this call has a method getNamespaceResolver(), and
you can use the NamespaceResolver to discover the in-scope
Variables are more difficult. The StaticContext object does not
allow you to discover which variables are in scope. There is a
reason for this: variables that exist statically might not have any
existence dynamically, because they might be optimized away. I would
recommend you use a design similar to that used by the
saxon:evaluate() extension, where parameters are passed explicitly
to the call.
On 02/10/2011 21:40, Full Midnight wrote:
I have looked on the web quite a bit for finding a solution to my
problem, but unfortunately I was not yet able to find too many
threads on my issue.
I have an XSLT transformation which, at a given time, calls an
"integrated extension function".
The argument passed to the extension function is a (dynamically
generated) XPath query String, like the one below:
The query above is executed on an XML fragment, which is
constructed separately as part of a standalone XPath instance
(i.e. using sxpath's IndependentContext, XPathEvaluator and
- "//namespace:message[(//myappnamespace:Order) and
xsd:integer(@id) gt xsd:integer($cursor/@last-id)
The query above, as you can see in bold, contains name-spaces and
variables from the XSLT transformation, so my questions are:
Thank you in advance!
- From within the extension function, is there somehow a way
to "expand" the (bold marked) XSLT variables, so that
the standalone XPath instance would receive the query above
without any "XSLT context" variables?
- For example, after such a "variable expansion" I would
have something like:
"//myapp1:message[(//myapp:Purchaseorder) and xsd:integer(12)
gt xsd:integer(46) ]"
- If not, how can I actually retrieve XSLT ((variables &
name-spaces) OR the entire XSLT context) and then pass them to
the standalone XPath instance?
- Please note: For performance reasons, I would prefer to
avoid the approach which assumes rebuilding each time the
standalone XPath instance (based on the XML fragment
+ XSLT variables), because multiple queries (like above) are
executed on the same XML fragment.
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
saxon-help mailing list archived at http://saxon.markmail.org/