- From: Philip Fennell <philip.fennell@gmail.com>
- Date: Mon, 30 Mar 2009 08:33:27 +0100
- To: xproc-dev@w3.org
James wrote: > My ext:xproc would then bring in all the inputs (apart from primary) in the > same way as I do external bindings I agree with you. I have to, in effect, do the same thing with my XProc processor when implementing the p:xslt step. I'm glad to see another example of the xproc step, it will prove very useful. Regards Philip Fennell 2009/3/29 James Fuller <james.fuller.2007@gmail.com>: > Hello, > > I have a crude test runner which I use with my xproc impl: > > <p:declare-step name="pipeline" > xmlns:p="http://www.w3.org/ns/xproc" > xmlns:t="http://xproc.org/ns/testsuite" > xmlns:c="http://www.w3.org/ns/xproc-step" > xmlns:ext="http://xproc.net/xproc/ext"> > > <p:input port="source" primary="true"/> > > <p:input port="input-port" primary="false" > select="/t:test/t:input[@port='source']/*"> > <p:pipe step="pipeline" port="stdin"/> > </p:input> > <p:input port="output-port" primary="false" > select="/t:test/t:output[@port='result']/*"> > <p:pipe step="pipeline" port="stdin"/> > </p:input> > <p:input port="pipeline-port" primary="false" select="/t:test/t:pipeline/*"> > <p:pipe step="pipeline" port="stdin"/> > </p:input> > > <p:output port="result" primary="true"/> > > <ext:xproc name="test-pipeline"> > <p:input port="source" select="/"> > <p:pipe step="pipeline" port="input-port"/> > </p:input> > <p:input port="pipeline" select="/"> > <p:pipe step="pipeline" port="pipeline-port"/> > </p:input> > </ext:xproc> > > <p:compare> > <p:input port="source"> > <p:pipe port="result" step="test-pipeline"/> > </p:input> > <p:input port="alternate"> > <p:pipe port="output-port" step="pipeline"/> > </p:input> > </p:compare> > > </p:declare-step> > > Which will run an xproc defined test (http://tests.xproc.org/) and > check that the output matches expected output. > > Two things to note is that my implementation (expressing impl freedom > ;) ) of p:compare result port is primary (which will change). > > The other is I have a ext:xproc which runs an xproc pipeline given an input. > > Plenty of the tests in the test suite define multiple inputs which > reflect that some steps have multiple inputs (p:xslt for example). > > I could choose to define ext:xproc with all known non primary inputs > but I would also have to define the corresponding top level inputs, > this approach is not really maintainable. > > perhaps this is a good example for the use of parameters? > > My ext:xproc would then bring in all the inputs (apart from primary) > in the same way as I do external bindings ... in any event, this > clarified the use case for parameters for me ... but I still find them > a little non intuitive. > > as an aside, is the name 'parameters' reserved e.g. is this possible > > <p:input port="parameters" kind="document"/> > > cheers, Jim Fuller > >
Received on Monday, 30 March 2009 07:34:07 UTC