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

These are all very intriguing ideas but I most certainly don't want
something as heavy as a full step (although I'm not against having that
feature as well).  The functions defined in XSLT (or XQuery) are very light
weight and an implementation that already has support for one or the other
can, in theory, expose them with the same semantics as when they are
otherwise used in XPath.

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.


On Thu, Aug 8, 2013 at 5:07 AM, Toman, Vojtech <vojtech.toman@emc.com>wrote:

> > -----Original Message-----
> > From: James Fuller [mailto:jim@webcomposite.com]
> > Sent: Thursday, August 08, 2013 12:12 PM
> > To: Toman, Vojtech
> > Cc: XProc WG
> > Subject: Re: Yet Another V2 Request: Extension Functions via XSLT 2
> >
> > that sounds like an interesting approach, though a little confused.
> >
> > I could see usefulness in being able to invoke steps themselves;
> >
> >     my:newstep($inputs as map:map, $outputs as map:map, $options as
> > map:map)
> >
> > but that doesn't make it entirely clear how functions in xquery/xslt
> > libs would be loaded into the in scope environment.
> >
> > so I will make a strawman;
> >
> > <p:xquery>
> > <p:input port="library">
> >    <p:document href="myxquerylib.xqy"/>
> >    <p:document href="myotherxquerylib.xqy"/> </p:input> </p:xquery>
> >
> > this could have the advantage of also loading in libs for the step
> > itself (instead of import in xquery)
> >
> > and in the above form (w/ no query port binding), it could load into in
> > scope environment.
> >
> > thoughts ?
>
> My idea was much simpler. Instead of importing the XSLT/XQuery functions
> directly, you would do that in XSLT/XQuery and then wrap the function you
> need you need in a separate p:xslt/p:xquery step:
>
> <p:declare-step name="my:great-function">
>   ...
>   <p:xquery>
>     <p:input port="query">
>       <p:inline>
>         <c:query>
>           import module namespace my='...' at '...';
>           my:great-function(...)
>         </c:query>
>       </p:inline>
>     </p:input>
>   </p:xquery>
> </p:declare-step>
>
> This approach has obvious limitations (verbose; the need for a separate
> step for each function; etc.), but it could do for simple things. Actually,
> if we wanted to support import XQuery/XSLT modules directly via
> p:import/p:document/etc., this could be, conceptually, what the processor
> does behind the scenes to expose those functions the XProc context.
>
> The question of how to invoke XProc steps in XPath expressions is another
> story. Passing maps for ports and options is one possibility, but perhaps
> we could do something simpler (by restricting ourselves to pipelines with
> certain signatures) and more XPath-y.
>
> Regards,
> Vojtech
>
> --
> Vojtech Toman
> Consultant Software Engineer
> EMC | Information Intelligence Group
> vojtech.toman@emc.com
> http://developer.emc.com/xmltech
>
>


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics