Support #5948
closed
fn:function-lookup and XSLT packages
0%
Description
Honestly: It isn't clear to me that this is supposed to work with packages. I'd sure like it to work, but tell me if I'm barking up the wrong tree.
The situation is that I have one package that provides component services, which uses function lookup to get access to information from the component-du-jour via callbacks.
When I do this with XQuery modules it is fine. With XSLT packages, the lookup always fails.
The meat is this, with $component containing information about the component.
function-lookup(QName($component("namespace"), "algorithm-parameters"), 2)
Example attached; run using test.sh (with appropriate adjustments to paths and config)
Files
Updated by Michael Kay over 1 year ago
- Subject changed from lookup-function and packages to fn:function-lookup and XSLT packages
- Priority changed from Low to Normal
Updated by Michael Kay over 1 year ago
OK, it calls function-lookup to get {http://mathling.com/art/backgrounds}algorithm-parameters#2. The current package is http://mathling.com/art/components. And it fails because the current package knows nothing of such a function.
The main package uses both components and backgrounds, but neither of these uses each other.
The spec for fn:function-lookup says that it looks "in the named functions component of the dynamic context "
The spec for the dynamic context in XSLT (ยง5.3.3.2) says this includes all the functions in the static context (plus an implementation-defined set of functions that are available dynamically but not statically.) The spec for the static context says that it includes
- The stylesheet functions defined in the containing package;
- Stylesheet functions defined in used packages, subject to visibility: see 3.5.2 Dependencies between Packages;
So the static context doesn't include the desired function, and therefore neither does the dynamic context.
So it's basically failing by design. It's trying to ensure that you can't use function-lookup to get around the visibility rules; you can't have a run-time dependency on a package that you didn't declare a compile-time dependency on.
My first though was that it would work if you declared the function with visibility="public". But that's not the problem (you actually expose it as public): you have to declare a "use-package" relationship as well.
Updated by Michael Kay over 1 year ago
- Tracker changed from Bug to Support
- Status changed from New to Closed
Closing this, as I believe the product is working correctly according to the spec.
Some facility to access the contents of a package dynamically, rather like load-xquery-module(), would be useful, but it's not currently available.
You could consider providing a public user-written function in a package that does a function-lookup within that package, and calling this in place of function-lookup; if necessary you could call this user-written function dynamically using fn:transform().
Updated by Mary Holstege over 1 year ago
Closing the loop: this is exactly what I did, and it works a treat. Thanks for the clarification.
Please register to edit this issue
.