W3C home > Mailing lists > Public > xproc-dev@w3.org > June 2013

Re: XProc testing; mock steps and v.next

From: James Fuller <james.fuller.2007@gmail.com>
Date: Mon, 3 Jun 2013 08:17:45 +0200
Message-ID: <CADsXk-bJzGvXdjAGwTOehE=RemsuHE_EU9gsmXtwywpK=e6fFg@mail.gmail.com>
To: Jostein Austvik Jacobsen <josteinaj@gmail.com>
Cc: XProc Dev <xproc-dev@w3.org>
On Tue, Mar 19, 2013 at 5:23 PM, Jostein Austvik Jacobsen
<josteinaj@gmail.com> wrote:
> So I've been fiddling with testing some XProc steps lately, and realized
> that there's no way (afaik) to create a "mock step" without editing either
> the step you want to test or the XML catalog. So it's not possible to do
> unit testing in XProc; only integration testing.

I agree, and I am implementing a resource manager approach within my
exp xproc processor ... I agree that mock testing is difficult today
in XProc.

> I think it would be useful to be able to override a URI that is already
> defined in a XML catalog. Say I want to test the following step:
> <p:declare-step type="x:mystep" xml:base="file:/tmp/mystep.xpl" ...>
>     <p:import href="http://www.example.com/mydependency.xpl"/>
>     ...
> </p:declare-step>

its unclear at what level in the syntax this could be exposed ... will
add to our 'bucket' list for vnext discussions.

> But I don't want x:mystep to invoke http://www.example.com/mydependency.xpl
> as it might produce non-deterministic side-effects. What if I could do
> something like this to override the XML catalog:
> <x:mystep>
>     <p:resource name="http://www.example.com/mydependency.xpl"
> uri="mockdependency.xpl"/>
> </x:mystep>
> The Resource Manager page on the v.next wiki[1] isn't very detailed yet but
> maybe it will be possible to do something like this with the planned
> resource manager?
> [1] http://www.w3.org/wiki/XProc_Resource_Manager
> (another thing that would make XProc testing easier would be dynamic
> pipeline execution; p:evaluate/cx:eval)

as an aside, if you would be willing to make a more formal submission
for the shape of an p:eval we could consider it for publication as a
Note, though no promises ... eval historically in any computing
context brings the worst out of people ;)

Jim Fuller

> Jostein
Received on Monday, 3 June 2013 06:18:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:17:11 UTC