Helpful input! I'll propose it to the EXPath list.
Christian
On Tue, Feb 18, 2014 at 1:29 PM, Hans-Juergen Rennau hrennau@yahoo.de wrote:
This makes very much sense to me, as these two functions deliver exactly the two alternatives for normalization (current working dir and tool dir).
Concerning static base URIs - I think you are right that it would not be guaranteed to be usable for resolving resource names - e.g. when the tool resides in a database. But on the other hand, whenever the containing module is a file, the static base URI shoud be set and should be usable for resolution.
I think there would not be any problem involved in base-dir. The function spec might adapt the words used for fn:resolve-uri:
"Resolving a URI does not dereference it. This is merely a syntactic operation on two strings."
e.g. like this: "The function result is not necessarily usable for resolving relative paths. It is merely the outcome of applying a syntactic operation to the static base URI."
Cheers, Hans-Juergen
Christian Grün christian.gruen@gmail.com schrieb am Di, 18.2.2014:
Betreff: Re: [basex-talk] Sought: a pattern of file:list usage An: "Hans-Juergen Rennau" hrennau@yahoo.de CC: "BaseX" basex-talk@mailman.uni-konstanz.de Datum: Dienstag, 18. Februar, 2014 13:03 Uhr
Come to think of it - maybe a
convenience function 'file:current-dir()' (= file:parent('.')) would be worthwhile, considering the importance of the current directory.
True; maybe we could add even two functions...
file:current-dir() file:base-dir()
...as in many cases it's also interesting to find paths relative to the query file directory. Would that make sense to you? I am not quite sure if all static base URIs can be resolved to local file paths, though.
Christian