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: Thu, 8 Aug 2013 03:24:31 -0400
To: XProc WG <public-xml-processing-model-wg@w3.org>
Message-ID: <F3C7EBECE80AC346BE4D1C5A9BB4A41F2F6AD294E2@MX11A.corp.emc.com>
See also a similar request in an older thread on xproc-dev:


There is, I believe, also a similar entry in the XProcVNext wiki.

But what about simply allowing to use XProc steps as XPath extension functions? That seems like a more robust and idiomatic solution than introducing "magic" mechanisms for native importing of XSLT/XQuery/whatnot modules.


Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group

> -----Original Message-----
> From: James Fuller [mailto:jim@webcomposite.com]
> Sent: Thursday, August 08, 2013 7:31 AM
> To: Alex Milowski
> Cc: XProc WG
> Subject: Re: Yet Another V2 Request: Extension Functions via XSLT 2
> On 8 August 2013 02:36, Alex Milowski <alex@milowski.com> wrote:
> > Let me explain the use case a bit better.  I have documents that are
> > typed, often on the root element, with specific RDFa types.  The
> > derived type is computed against the @vocab attribute (and others)
> > along with the @typeof attribute.  I want to expose an extension
> > function so I can do something like this:
> >
> > <p:choose>
> > <p:when test="rdfa:is-type(/*,'http://example.com/Book')">
> > So, I really just want a way in p:library to declare these functions.
> > I could imagine just importing an XSLT library directly but I wonder
> > whether that is technical feasible given existing implementations.
> its an interesting idea and I think it would leverage other XML
> technologies reuse mechanisms. In MarkLogic land, allowing XSLT to
> import xquery modules proves to be a big winner and I suspect the
> reverse would be true as well.
> We could consider overloading p:import to be able to load in functions,
> in the scope of the current pipeline or a p:import in a p:library. Heck
> ... why not javascript as well or whatever else an impl may decide ? We
> could add a content-type attribute as the means for unambiguously
> identifying function library.
> For example, with the xproc impl I am working on, it would be
> straightforward to load in xquery modules whose functions could be made
> available, though I don't know how this would work with XSLT and would
> have to tinker about calabash/saxon as an example to fully understand
> how an impl would achieve this.
>  J
Received on Thursday, 8 August 2013 07:25:10 UTC

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