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

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.

Regards


On Mon, Jan 16, 2012 at 6:32 PM, Geert Josten <geert.josten@dayon.nl> wrote:



An expression like: resolve-uri('./', $lib-base-uri) gives you the
directory with an ending slash.



But David makes sensible remarks. It could well be that even this approach
does not return a useful uri..


-- 

On Mon, Jan 16, 2012 at 9:59 PM, Norman Walsh <ndw@nwalsh.com> wrote:

> David Lee <dlee@calldei.com> writes:
> > Not speaking for the WG ... but  it won't keep me from speaking :)
>
> You know, you work for a member company now, ...
>
> > 1) The XProc "file" may not be a file, it could be
> >
> > A) In a database (such as EMC  ...)
> >
> > B) Prepared dynamically
> >
> > D) Directly fetched/executed off the internet (http:// ... )
> >
> > 2) Not all OS's *HAVE* the notion of a CWD.   For example Windows Mobile
> has no concept of a
> > CWD.
>
> Yes, those are the sorts of reasons that the WG didn't attempt to specify
> the CWD.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 413 624 6676
> www.marklogic.com
>



-- 
Alex Muir
Instructor | Program Organizer - University Technology Student Work
Experience Building
University of the Gambia
http://sites.utg.edu.gm/alex/<https://sites.google.com/a/utg.edu.gm/utsweb/>

Low budget software development benefiting development in the Gambia, West
Africa
Experience of a lifetime, come to Gambia and Join UTSWEB -
http://sites.utg.edu.gm/utsweb/<https://sites.google.com/a/utg.edu.gm/utsweb/>

Received on Wednesday, 18 January 2012 09:36:46 UTC