W3C home > Mailing lists > Public > xproc-dev@w3.org > January 2012

Re: why not in p:exec ... ""If cwd is not specified, the cwd is the same as the xproc file one is running."?

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 18 Jan 2012 07:00:40 -0500
To: XProc Dev <xproc-dev@w3.org>
Message-ID: <m28vl5md93.fsf@nwalsh.com>
Alex Muir <alex.g.muir@gmail.com> writes:
> Thanks for the simpler way and the explanation, although other steps
> seem to rely on a concept of cwd being the directory the xproc file
> is in for example xslt files are referenced as relative to the
> location of the xproc file so I'm not clear on the reasons p:exec
> would differ from those and a bit interested to know why as I assume
> there is a reason.

Most XML tools resolve links relative to the base URI of some element.
That's the way that href links in XProc and XSLT files work, for example.
Those steps can fail if there is no base URI.

The spec could have said that the CWD for p:exec should be the same
directory as the directory that contains the XProc pipeline document,

1. What about pipelines that are accessed by http?
2. What about pipelines that arrive on stdin?
3. What about operating environments that have no concept of a CWD?

The spec could have said "should" I suppose with caveats.

But there's also the question of whether or not that's the right thing.

The build script for my XProc book uses p:exec and relies on the fact
that "bin/perlscript.pl" will do the right thing. I could have written
it so that "../bin/perlscript.pl" would do the right thing, of course,
but then perlscript.pl has to be changed to look in ".." for config files
and such, at least potentially.

The p:exec step has a cwd option; you can certainly write your own pipeline
library that contains my:exec that does the exact same thing as p:exec except
it sets the cwd option appropriately.

                                        Be seeing you,

Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676

Received on Wednesday, 18 January 2012 12:01:19 UTC

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