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

then maybe the best approach (and coming full circle ) we consider
some kind of namespace binding mechanism, akin to what EPATH packaging
is proposing ?

thoughts ?



On 08/08/2013, Alex Milowski <alex@milowski.com> wrote:
> 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
>

Received on Thursday, 8 August 2013 18:30:00 UTC