W3C home > Mailing lists > Public > xproc-dev@w3.org > July 2010

RE: Can a pipeline 'call' itself?

From: Philip Fennell <Philip.Fennell@marklogic.com>
Date: Tue, 27 Jul 2010 12:40:54 -0700
To: "HILLMAN, Tomos" <tomos.hillman@oup.com>, "xproc-dev@w3.org" <xproc-dev@w3.org>
Message-ID: <D20C296D14127D4EBD176AD949D8A75A45F77CCA@EXCHG-BE.marklogic.com>

You can certainly do recursion in XProc pipelines. The example pipeline below was used to test a 'paged' Atom feed. The step of type 'test:get-page' tests, using a p:choose, for the presence of a 'next' link in the feed and keeps calling itself until there is no 'next' link at which point it exits. I haven't run it recently so I can't say it'll work straight-off but the principle is valid. How that exactly fits what you're trying to do I can't say but it might help.



<?xml version="1.0" encoding="UTF-8"?>
		exclude-inline-prefixes="atom c cx p pxp test xs"
	<p:serialization port="result" indent="true" omit-xml-declaration="false" 
			method="xml" encoding="utf-8" media-type="application/xml"/>
	<p:input port="source" sequence="false">
	<p:output port="result" sequence="false"/>
	<p:import href="../lib/library-1.0.xpl"/>
	<p:import href="lib/core.xpl"/>
	<p:declare-step name="feed-page" type="test:get-page">
		<p:input port="source" sequence="false"/>
		<p:output port="result" sequence="false"/>
		<p:option name="href"/>
		<p:option name="entries-per-page"/>
		<p:option name="index"/>
		<p:load name="get-feed">
			<p:with-option name="href" select="concat($href, '?max-results=', $entries-per-page ,'&amp;start-index=', $index)"/>
		<p:insert name="insert-page" match="/test:results" position="last-child">
			<p:input port="source">
				<p:pipe step="feed-page" port="source"/>
			<p:input port="insertion">
				<p:pipe step="get-feed" port="result"/>
			<p:with-option name="message" select="concat('[test:get-page] ', /test:results/atom:feed[last()]/atom:link[@rel = 'self']/@href)"/>
			<p:when test="/test:results/atom:feed[last()]/atom:link[@rel = 'next']">
					<p:with-option name="href" select="$href"/>
					<p:with-option name="entries-per-page" select="$entries-per-page"/>
					<p:with-option name="index" select="/test:results/atom:feed[last()]/as:endIndex"/>
	<test:get-page href="" entries-per-page="4" index="0"/>
<!--	<test:get-page href="https://api.test.foo.co.uk/atomstore/v1/pets/dogs/" entries-per-page="4" index="0"/>-->
	<p:validate-with-schematron name="validate">
		<p:input port="source"/>
		<p:input port="parameters">
		<p:input port="schema">
			<p:document href="atom-6/schema/paged-feeds.sch"/>
		<p:log port="result" href="logs/atom-6.xml"/>
		<p:input port="source">
			<p:pipe step="validate" port="report"/>

-----Original Message-----
From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On Behalf Of HILLMAN, Tomos
Sent: 27 July, 2010 6:08 PM
To: xproc-dev@w3.org
Subject: Can a pipeline 'call' itself?

Hi List,

I'm tinkering with some chunking scripts (again!), and would appreciate some advice on how to approach a problem.

Essentially our (document based) data has some 'floating' structures which are called in at relevant points in the XML using processing instructions (please don't suggest alternative data models; that's well outside the scope of the problem!).  These are often stored elsewhere in the document compared to the XML we might wish to extract into a 'chunk'.  Fairly straightforward so far; I can successfully pull floats into the chunk from the original complete document based on references within that chunk.

The issue is that these floating structures may themselves refer to other floating structures; therefore some form of recursion (and testing) is required.  What is the best way of approaching this?  I assume that it's not XProc's 'way' to have a procedural 'do.. until' structure - is the alternative to build a timeline that 'calls' itself?

Thanks in advance,


Oxford University Press (UK) Disclaimer

This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. OUP does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of OUP. If this email has come to you in error, please delete it, along with any attachments. Please note that OUP may intercept incoming and outgoing email communications.
Received on Tuesday, 27 July 2010 19:41:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:07 UTC