- 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, except: 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, norm -- Norman Walsh Lead Engineer MarkLogic Corporation Phone: +1 413 624 6676 www.marklogic.com
Received on Wednesday, 18 January 2012 12:01:19 UTC