- From: James Fuller <jim@webcomposite.com>
- Date: Thu, 8 Aug 2013 20:29:33 +0200
- To: Alex Milowski <alex@milowski.com>
- Cc: XProc WG <public-xml-processing-model-wg@w3.org>
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