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