This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17601 - [XQ31] Importing XSLT function libraries
Summary: [XQ31] Importing XSLT function libraries
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-26 12:11 UTC by John Snelson
Modified: 2014-09-15 09:25 UTC (History)
6 users (show)

See Also:


Attachments
Importing XSLT in XQuery (57.18 KB, application/pdf)
2014-07-22 16:08 UTC, O'Neil Delpratt
Details

Description John Snelson 2012-06-26 12:11:01 UTC
XQuery should have the ability to import and use functions from XSLT. It should possibly also be able to use other things declared in the stylesheet, like global variables/parameters, modes, etc.

This was part of an unmet requirement of XQuery 3.0:

http://www.w3.org/TR/xquery-30-requirements/#invocation-of-external-functionality
Comment 1 Jonathan Robie 2013-01-08 16:57:53 UTC
We discussed this in meeting #523 and decided that this should be a "may".

<quote>
Q2.9.16 Bugzilla Bug 17601, [XQ31ReqUC] Importing XSLT function
libraries
See http://www.w3.org/Bugs/Public/show_bug.cgi?id=17601

include in requirements document as a MAY
</quote>
Comment 2 Jim Melton 2013-07-30 18:40:15 UTC
This bug has been redirected to the XQuery 3.1 document, as it has been accepted as a requirement (a MAY requirement).
Comment 3 Jonathan Robie 2013-11-11 10:06:34 UTC
Minutes from today's meeting:

John suggests using packaging to define the semantics of importing
XSLT function libraries.

Jonathan suggests defining a function that specifies the stylesheet
(as a node or a URI), the instance to be transformed (as a node or a
URI), and a map with the XSLT 2.0 parameters.  Perhaps this is the
minimum required to declare victory?

Decided:

MUST: be able to invoke stylesheet with params in XQuery 3.1

SHOULD: XQuery 3.1 should have built-in support for calling functions in XSLT 3.0

MUST: recommend to the XSLT WG that XSLT 3.0 must define a way to
invoke functions

MUST: An XQuery top-level expression that invokes an XSLT
transformation MUST be able to access the (primary) result document of
that transformation and MAY be able to access any other documents
created by that transformation

MAY: be able to invoking xslt 2.0 functions from XQuery 3.1 using
semantics defined in XSLT 3.0 packaging

MUST: allow either a URI or a node to identify either a stylesheet or
content to be transformed

Action A-###-###: Mary to update her proposal based on the following
requirements (fold into the action item, except the XSLT 3.0
requirement)

Action A-###-###: Jim to forward the XSLT requirement to the XSLT WG.

Loren notes how Exist does this:

http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/transform&location=java:org.exist.xquery.functions.transform.TransformModule

Josh may propose something along these lines:

declare %ora-xslt:binding(“file:/path/to/my.xslt”)  function local:my-xslt-transform($input as document-node()) as document-node() external;
Comment 4 Christian Gruen 2013-11-11 10:11:04 UTC
Thanks for the dicscussion. This is how it’s done in BaseX: http://docs.basex.org/wiki/XSLT_Module
Comment 5 Adam Retter 2013-11-11 13:17:38 UTC
I would comment that I am sure we have discussed this in great detail in the past at the last Prague F2F (and perhaps even the one before that). The only thing I will add, is that if I remember correctly (and I may well not), we put this on hold until 'maps' was to be done. The reason being that many wanted to pass parameters to the Transformation, and to be able to provide document nodes etc, we needed a data structure that would not loose that identity information.
Comment 6 Mary Holstege 2013-11-11 16:11:06 UTC
And, here is how MarkLogic does it: http://docs.marklogic.com/xdmp:xslt-eval
and http://docs.marklogic.com/xdmp:xslt-invoke
Comment 7 John Snelson 2013-11-11 16:31:13 UTC
(In reply to Adam Retter from comment #5)
> I would comment that I am sure we have discussed this in great detail in the
> past at the last Prague F2F (and perhaps even the one before that). The only
> thing I will add, is that if I remember correctly (and I may well not), we
> put this on hold until 'maps' was to be done. The reason being that many
> wanted to pass parameters to the Transformation, and to be able to provide
> document nodes etc, we needed a data structure that would not loose that
> identity information.

The difference here is that we are considering this in the context of XQuery 3.1 where we have maps to be able to solve this.

Speaking for myself, I have a tiny brain with little recollection, and would value any input you have on what the requirements or details for such an API would look like. In particular, are you hoping to simply "eval" an XSLT stylesheet, or do you also have aspirations to be able to import XSLT function libraries etc.
Comment 8 O'Neil Delpratt 2014-07-22 16:08:57 UTC
Created attachment 1497 [details]
Importing XSLT in XQuery

proposal attached
Comment 9 Michael Kay 2014-09-10 15:47:39 UTC
A specification for the fn:transform() function has been added to the spec and accepted as status quo by the working group, while requesting members to review it carefully.
Comment 10 Michael Kay 2014-09-15 09:25:54 UTC
Note that although the proposed function does not import XSLT functions into the static context as originally suggested, it does make XSLT functions callable from XQuery and this has been deemed to satisfy the requirement. Closing accordingly.