W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2013

RE: Yet Another V2 Request: Extension Functions via XSLT 2

From: Toman, Vojtech <vojtech.toman@emc.com>
Date: Fri, 9 Aug 2013 02:59:57 -0400
To: "public-xml-processing-model-wg@w3.org" <public-xml-processing-model-wg@w3.org>
Message-ID: <F3C7EBECE80AC346BE4D1C5A9BB4A41F2F6AD295A2@MX11A.corp.emc.com>
> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Thursday, August 08, 2013 9:02 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: Re: Yet Another V2 Request: Extension Functions via XSLT 2
> Alex Milowski <alex@milowski.com> writes:
> > I would expect this feature to be static and an XProc processor can
> > refuse to compile the pipeline if it doesn't support the
> implementation language.
> I've poked about a bit. I'm having a hard time getting all the bits
> connected together, but in theory this:
>    <cx:import namespace="http://xmlcalabash.com/ns/functions"
> href="f.xqy"/>
> will load functions from f.xqy and store them in the processor so that
> they can be called as extension functions. It might (should!) also be
> possible to load functions defined in XSLT too.

Interesting. What about importing functions/modules declared inline in the XProc pipeline?

I am also wondering about the implications of the above on the XProc processor XPath context. It would probably mean, among other things, that we would have to make the function library in the XPath context scoped, similar to what we do with variable bindings.


Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
Received on Friday, 9 August 2013 07:00:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:52 UTC