This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XSLT should have a way to invoke XQuery, including one or more of these ways: 1. Dynamic evaluation, in the same way that eval() is currently used to evaluate XPath expressions 2. Importing an XQuery library, so that its functions can be called from a stylesheet 3. Embedding XQuery in a stylesheet
Has the XSL WG made any progress on this? Can we make this a high priority for the joint portion of upcoming telcons?
The XSL WG has just published its FPWD of XSLT 2.1, and all work on enhancements was put on hold until that was done. The direction I'm most inclined to pursue is (2): perhaps a new declaration of the form <xsl:import-library language="xquery" href="location-uri"/> which imports the functions and global variables from the specified XQuery library module, with lower import precedence than the importing module. There are obviously details to be sorted out (such as whether it makes sense to specify a module URI as well as or instead of a location URI) but it shouldn't be too difficult. It would have to be an optional feature. Doing (3) has all sorts of complications because XQuery is not XML. There are other XML-based languages that would like to embed XQuery, for example XForms, and if a suitable (XML-based but human-readable) representation of XQuery were defined, then we could consider using it embedded in XSLT. We've now got dynamic XPath evaluation in XSLT 2.1, and my feeling is that meets enough of the requirement to make dynamic XQuery evaluation unnecessary for the time being.
(In reply to comment #2) > The direction I'm most inclined to pursue is (2): perhaps a new declaration of > the form <xsl:import-library language="xquery" href="location-uri"/> which > imports the functions and global variables from the specified XQuery library > module, with lower import precedence than the importing module. There are > obviously details to be sorted out (such as whether it makes sense to specify a > module URI as well as or instead of a location URI) but it shouldn't be too > difficult. It would have to be an optional feature. This would make me happy.
I would add: 4. Invoke queries (statically known), e.g., xquery-invoke("query.xqy", $src). Nice to have would be a third argument or some way to pass parameters (to initialize external variables in the query). I know of an implementation (not yet released) that does both #2 and #4 (via an extension element and extension function, respectively). For inspiration on possibilities around #3, be sure to refer to: http://www.jclark.com/xml/construct.html
Noted that one could simply allow xsl:include/xsl:import to resolve to a query library module. (Perhaps with a media-type attribute to say what kind of thing you expect the URI to resolve to.) One could also extend xsl:evaluate to call XQuery instead of XPath; or a function to load and execute XQuery from a file. Note the security implications (injection attacks). See minutes of today's discussion (member-only). Need to come back to this later.
For the convenience of those with member-access; the minutes referred to in the previous comment are at http://www.w3.org/XML/Group/2010/07/xsl-ftf-minutes.xml
In discussion today, the sentiment of the Working Group was that the most important requirement / use case was (2) (importing an XQuery library), giving the ability to develop a single function library that could be used from both XSLT and XQuery. The WG felt that this should be developed as part of the programme of work on separate compilation.
What is the status on this?
The current editor's draft contains proposed text (for review by the WG) to handle this requirement in section 3.6.5. https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview.html#xquery-packages (member-only; mutable URI). Note that this is designed to meet point (2) of the original requirement, that is, import of an XQuery library module.