- From: <bugzilla@jessica.w3.org>
- Date: Thu, 14 Jan 2016 12:08:03 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29374 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