My use case may well be not very typical. I have created an abstraction for passing sets of filesystem or database resources (resource sets) around. They achieve something similar as Ant file sets and have an XML representation but internally are represented as maps. When creating them I want to make sure they point to a specific location that cannot change. I also pass information from these resource sets into XSLT (which may have an entirely different concept of current dir) and it needs to be able to find these resources as well.
Here's a serialized example of such a resource set.
{ "meta": { "export-date": "27-10-2014", }, "base": "file:///F:/home/marcg/work/projects/website/_from_cms/locale/EN/xml", "selectors": { "includes": "*.xml", "excludes": () }, "type": "set", "id": "source" }
--Marc
On Tue, Oct 28, 2014 at 3:58 PM, Christian Grün christian.gruen@gmail.com wrote:
Sorry in my example I should've used a relative path because that's what I'm processing most of the time and I use it to resolve to an absolute path. However I'm working with file sets for which the directory at that time may not yet exist.
I see. Personally, I didn't use file:resolve-path() at all; what's your reason for working with absolute paths?
Guess, I will keep the 'fix' in a wrapper function then. Personally I don't see the rationale for this in the spec.
It's surely something that could be discussed a bit more (however, it could already a bit late).
C.