[Bug 9069] New: Function to invoke an XSLT transformation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 9069] New: Function to invoke an XSLT transformation

bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

           Summary: Function to invoke an XSLT transformation
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Functions and Operators 1.1
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]
         QAContact: [hidden email]


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.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #1 from Jonathan Robie <[hidden email]>  2010-05-12 13:00:24 ---
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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069


Evan Lenz <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #2 from Evan Lenz <[hidden email]>  2010-05-12 18:43:59 ---
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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #3 from Michael Kay <[hidden email]>  2010-09-14 16:26:50 ---
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?

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069


David Carlisle <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #4 from David Carlisle <[hidden email]>  2010-09-14 16:35:58 ---
(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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #5 from Jonathan Robie <[hidden email]>  2010-09-14 18:04:17 ---
> 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).

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #6 from Evan Lenz <[hidden email]>  2010-09-14 18:18:17 ---
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).

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #7 from Michael Kay <[hidden email]>  2010-09-14 22:46:58 ---
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).

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #8 from Jonathan Robie <[hidden email]>  2010-09-15 14:44:03 ---
(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?

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #9 from Michael Kay <[hidden email]>  2010-09-15 15:01:07 ---
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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069





--- Comment #10 from Jonathan Robie <[hidden email]>  2010-09-15 15:34:04 ---
(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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

Adam Retter <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #11 from Adam Retter <[hidden email]> 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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

--- Comment #12 from Michael Kay <[hidden email]> 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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

--- Comment #13 from Jonathan Robie <[hidden email]> 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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

--- Comment #14 from Evan Lenz <[hidden email]> 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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

--- Comment #15 from Michael Kay <[hidden email]> 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.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

--- Comment #16 from Adam Retter <[hidden email]> 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()?

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

Liam R E Quin <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |[hidden email]
         Resolution|                            |LATER

--- Comment #17 from Liam R E Quin <[hidden email]> 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)

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 9069] Function to invoke an XSLT transformation

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by bugzilla (Bugzilla)-14
https://www.w3.org/Bugs/Public/show_bug.cgi?id=9069

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
         Resolution|LATER                       |FIXED

--- Comment #18 from Michael Kay <[hidden email]> ---
This function is now included in F+O 3.1. Changing the status from
"Resolved/Later" to "Closed/Fixed".

--
You are receiving this mail because:
You are the QA Contact for the bug.