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 9069 - Function to invoke an XSLT transformation
Summary: Function to invoke an XSLT transformation
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 enhancement
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: 2010-02-18 16:14 UTC by Jonathan Robie
Modified: 2014-09-15 09:24 UTC (History)
6 users (show)

See Also:


Attachments

Description Jonathan Robie 2010-02-18 16:14:00 UTC
F&O should have a function to invoke an XSLT transformation. 

This would be very useful for XQuery implementations that need to call a transform.
Comment 1 Jonathan Robie 2010-05-12 13:00:24 UTC
Anyone from the XSL WG willing to take this one on? Personally, I think this is important for the 1.1 time frame. We need these two languages to be able to invoke each other.
Comment 2 Evan Lenz 2010-05-12 18:43:59 UTC
This is something that I think XSLT itself has needed for a long time, i.e. invoking a stylesheet as a black box (although the default-mode stuff and possibility of chameleon modes helps lessen the pain some).

If there's a way to invoke XSLT from XQuery, it should be provided uniformly to XSLT itself as well. xquery-invoke() and xslt-invoke() (or whatever they're called) should both available to both XSLT and XQuery.
Comment 3 Michael Kay 2010-09-14 16:26:50 UTC
The design question is how much capability/flexibility to provide given the limitations of the function call mechanism. For example, it's difficult to provide an effective way of passing parameters to the transformation (unless we add maps to the language, something which XSL WG is seriously discussing.) Would a simple R = transform(I, S) function be sufficient, where I is the principal source document, S the principal stylesheet module, and R the result document?
Comment 4 David Carlisle 2010-09-14 16:35:58 UTC
(In reply to comment #3)

> Would a simple R = transform(I, S) function be sufficient, where I is the
> principal source document, S the principal stylesheet module, and R the result
> document?


Probably that would be sufficient. As you know the saxon:transform extension allows an optional third param that allows string valued parameters to be specified, but when using this I've often found it more convenient to just to generate within the calling stylesheet a new top level stylesheet that defines the global parameters and then imports the existing external stylesheet that you want to invoke.
Comment 5 Jonathan Robie 2010-09-14 18:04:17 UTC
> Would a simple R = transform(I, S) function be sufficient, where I is the
> principal source document, S the principal stylesheet module, and R the result
> document?

I think so.

If we decide we need to specify parameters, we could use the same approach that we use for serialization parameters (see Bug 9302).
Comment 6 Evan Lenz 2010-09-14 18:18:17 UTC
I think it would suffice as well. Parameter-passing would be nice-to-have, but not essential in most cases. If you do add maps, I hope they would not be stateful (as in MarkLogic's map:map extension implementation).
Comment 7 Michael Kay 2010-09-14 22:46:58 UTC
We're currently talking about adding an immutable map to XSLT as a new data type (the put operation would return a new map). There appear to be a number of possible efficient implementations. It would be ideally suited for this purpose, because unlike the mechanism used for serialization parameters, the values can be any data type (including nodes), not only strings.

There are other questions about the detailed spec as well, of course. Little details like what is the base output URI of the transformation (one reason for using the function might be to exploit XSLT's capability to generate multiple output files: but on the other hand, that makes the transform() function a wee bit side-effecting).
Comment 8 Jonathan Robie 2010-09-15 14:44:03 UTC
(In reply to comment #7)
> We're currently talking about adding an immutable map to XSLT as a new data
> type (the put operation would return a new map). There appear to be a number of
> possible efficient implementations. It would be ideally suited for this
> purpose, because unlike the mechanism used for serialization parameters, the
> values can be any data type (including nodes), not only strings.

If this function is in F&O, how would an XQuery implementation invoke it using an immutable map? Would that require adding an immutable map to XQuery as well? Would this be a new type in the data model?

Would a map also have an XML serialization?
Comment 9 Michael Kay 2010-09-15 15:01:07 UTC
In response to comment #8, needs discussion in the WGs. At present we're trying to thrash out the design of a datatype that meets the requirements for XSLT streaming. When we've done that, we'll discuss with XQuery WG whether to make the data type XSLT-only or add it to XQuery as well. If it does get added to XQuery (and I know there will be resistance on grounds of timescales) then it will be useful in specifying this function.
Comment 10 Jonathan Robie 2010-09-15 15:34:04 UTC
(In reply to comment #9)

I opened the bug because we need this functionality in XQuery, which does not have maps. I don't think we need a new data type to add a function to the function library, or to allow parameters to be specified.

I would hope that a function designed in response to a request from the XML Query Working Group could be called from the existing XQuery language.
Comment 11 Adam Retter 2010-11-01 10:36:36 UTC
(In reply to comment #6)
> I think it would suffice as well. Parameter-passing would be nice-to-have, but
> not essential in most cases. If you do add maps, I hope they would not be
> stateful (as in MarkLogic's map:map extension implementation).

I would argue that being able to pass parameters to the stylesheet is required. If we dont support this functionality now, then it will need to be added sooner or later. Some implementations (including eXist-db) already provide a proprietary function for invoking XSLT from XQuery - e.g. transform:transform($node-tree as node()?, $stylesheet as item(), $parameters as element(parameters)?) as node()

At present in eXist-db $parameters is really a constructed node of the form -

<parameters>
<param name="some-name" value="some-value"/>
<param name="other-name"><a/></param-name>
</parameters>

I am not necessarily advocating exactly the same approach, however I do feel that parameter passing is important. XSLT allows external parameters so we should really try and support them. The approach could be similar to that used for fn:serialize in F&O 1.1.
Whilst it could be done by creating some sort of map datatype, do we not already have enough scope through constructed nodes?
I cannot speak for all implementations or use-cases, but typically the parameters are smaller than the XSL document itself and as such I would expect paramaters as constructed nodes to be a more efficient approach than reconstructing the XSLT as suggested in comment #4.
Comment 12 Michael Kay 2010-11-01 17:04:01 UTC
I'm a little reluctant to go with a mechanism that allows string-valued parameters, but not for example booleans or nodes. Although it might meet 80% of use cases, we would be locked in to this design for all time and there's no obvious way to extend it to meet 100% of the requirement.

Another possibility - less simple but more general - would be to supply as a parameter a function which maps parameter names to parameter values.
Comment 13 Jonathan Robie 2010-11-01 17:43:17 UTC
(In reply to comment #12)
> I'm a little reluctant to go with a mechanism that allows string-valued
> parameters, but not for example booleans or nodes. Although it might meet 80%
> of use cases, we would be locked in to this design for all time and there's no
> obvious way to extend it to meet 100% of the requirement.

If we pass parameters in an XML instance, all of these requirements can be met.

> Another possibility - less simple but more general - would be to supply as a
> parameter a function which maps parameter names to parameter values.

What advantages do a map or such functions have over an XML instance containing the parameter / value pairs? Both XQuery and XSLT can create XML instances very simply.
Comment 14 Evan Lenz 2010-11-01 18:38:36 UTC
Using XML to pass parameters would require defining how arbitrary XPath values are represented in XML (trivial for strings, but not for everything else). I like the mapping function idea, particularly because it avoids the need to create a new data type.
Comment 15 Michael Kay 2010-11-01 22:13:37 UTC
>What advantages do a map or such functions have over an XML instance containing
the parameter / value pairs?

While string values could be used (via casting) to supply values for any parameter whose type is atomic, it's hard to see how this mechanism could be used for the common case of a parameter whose required type is a document node.
Comment 16 Adam Retter 2010-11-02 08:54:17 UTC
(In reply to comment #12)
> I'm a little reluctant to go with a mechanism that allows string-valued
> parameters, but not for example booleans or nodes. Although it might meet 80%
> of use cases, we would be locked in to this design for all time and there's no
> obvious way to extend it to meet 100% of the requirement.
> 
> Another possibility - less simple but more general - would be to supply as a
> parameter a function which maps parameter names to parameter values.

So are you saying that such an example would make use of higher order functions? Perhaps like - 

Signature - fn:transform($node-tree as node()?, $stylesheet as item(), $parameters as function(*)?) as node()?
Comment 17 Liam R E Quin 2011-07-27 21:20:06 UTC
[[
DECISION: close 9069 as LATER, because it's not worth doing without
a mechanism such as maps to supply parameters.

]] (Joint meeting 482, July 27th 2011)
Comment 18 Michael Kay 2014-09-15 09:24:02 UTC
This function is now included in F+O 3.1. Changing the status from "Resolved/Later" to "Closed/Fixed".