This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.
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?
(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.
> 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).
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).
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).
(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?
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.
(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.
(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.
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.
(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.
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.
>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.
(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()?
[[ 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)
This function is now included in F+O 3.1. Changing the status from "Resolved/Later" to "Closed/Fixed".