W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2016

[Bug 29374] fn:transform

From: <bugzilla@jessica.w3.org>
Date: Thu, 14 Jan 2016 12:08:03 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29374-523-68QmsIaVtQ@http.www.w3.org/Bugs/Public/>

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
Naming is always tricky, but there's a big difference here. The
fn:load-query-module loads a module and exposes its functions, but does *not*
execute it. The fn:transform actually invokes a transformation, but does *not*
make its functions available (this does, however, beg the question: why can't
we load an xslt module or package?).

Your argument suggests that because you are "already in XQuery, it should be a
short name". But these are XPath Functions and Operators shared between
multiple languages, fn:load-query-module is therefore also available from XSLT
and any other language or environment that exposes F&O.

Since the words load or load-module could mean multiple things, I think the WG
made a good decision here. Likewise, transform is a verb used primarily with
XSLT, so the added prefix "xsl" seems redundant.

The function was added by the joined WG's, only recently they asked the XSL WG
to update the spec such that it reflected the new state the XSLT spec is in. It
seems only reasonable that if in F&O you add a function for XQuery, you also
add something for XSLT, as both are the prime languages where F&O is used in.

Whether or not an XQuery processor supports the fn:transform function or an
XSLT processor supports the fn:load-query-module function is highly dependent
on the implementations and yes, this may mean that such an implementation
allows you to configure an external, extra xquery/xslt processor for this task.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 14 January 2016 12:08:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:57 UTC