On 28/02/2022 22:07, George Joseph wrote:
> Actually "//*[name()='dm:device']" works as well so maybe that's what I'll do.
This seems like the best work-around.
Yeah makes sense. I'll need to do some performance testing regardless
of which way I go since I'm parsing SIP messages in real time.
> Is there any reason why path parameters with namespaces haven't been
> supported?
> Would a pull request to add the namespaces in xsltNewTransformContext be
> considered?
How parameters are passed isn't covered by the standard, so it's up to the
implementation to come up with something. It seems natural to allow XPath
expressions, but it's not clear how to handle namespaces. Simply taking the
namespace defitinions from the root element of the root stylesheet should do
what most people expect, but it is somewhat fragile.
True.
1. Passing parameters from the command line
Supporting namespaces in a clean way would probably require a separate channel
to register namespaces just for parameter evaluation. Even Saxon doesn't seem
to support custom namespaces in parameter expressions:
"The static context for this XPath _expression_ includes only the standard
namespaces conventionally bound to the prefixes xs, fn, xsi, and saxon." [1]
2. Passing parameters using the API
The most flexible approach is probably an API to set parameters directly,
similar to Saxon's XsltTransformer [2]. This would even allow to pass nodes
from external documents as parameters. But if you want to combine that with
XPath expressions, you'd have to evaluate them yourself.
Nick
Gotcha. Thanks for all your help Nick!
[1] https://www.saxonica.com/documentation11/index.html#!using-xsl/commandline
[2]
https://www.saxonica.com/documentation11/index.html#!javadoc/net.sf.saxon.s9api/XsltTransformer@setParameter