- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 04 Feb 2015 08:55:08 -0600
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <874mr1pvzn.fsf@nwalsh.com>
Hello world, In some senses, the biggest gains in XProc usability would come from the ability to use XProc more naturally in XPath expressions. One could even imagine, if we made that possible, that XProc could be used from other XPath frameworks. Two crazy ideas drifted through my head this morning: <p:variable name="whatever" as="map(xs:string,item()*)"> { subpipeline } </p:variable> That is, the value of that variable is a map from the names of the output ports on the final step to the sequences of items that appeared on the respective port. There'd have to be some pretty tight constraints about what a variable's pipeline can "see" or you'd be able to write loops. That extends pretty naturally to <p:function name="myfunc" as="map(xs:string,item()*)"> <p:param name="input" as="document-node()*"/> <p:identity> <p:input port="source" select="$input"/> </p:identity> </p:function> Here a restriction that says no pipes that "leave" the function are allowed bites less severely because you can pass anything you need into it. It's also self-contained so it can't introduce loops. Presumably you could later do: <p:store href="{if (empty(map:get($whatever,"result")) or empty(map:get(myfunc(($a,$b,$c)),"result"))) then $this else $that}"/> It would probably be convenient to think of a way to make it possible for $whatever and myfunc() to return a single sequence and not a map in the case where there was only one output port. Be seeing you, norm -- Norman Walsh Lead Engineer MarkLogic Corporation Phone: +1 512 761 6676 www.marklogic.com
Received on Wednesday, 4 February 2015 14:55:39 UTC