Hi @daliboris — good to see you in Kraków!

Hmmm … my oXygen (27.1) does not list ${cf} when I try to set up a new transformation scenario and click on the little “Insert Editor Variables” button (a yellow ellipsis under a green down-arrow). And both the field names¹ and the descriptions² of the variables I do see suggest that the values here are URLs, not filepaths. Since URLs use ‘/’ not ‘\’, this would seem like it might be a bug in oXygen. But if they do have a variable correctly returning a path (and your error msg sure makes it look that way) I think such a fix is quite reasonable.

Does it work? I do not have any way to test it. I worry that the string-join(), because it is sticking a slash in between each member of the sequence, will return a string that starts with file://// instead of the desired file:/ or file:///. (I am not sure it would make a difference on a Windows system, though.)

notes
¹ “XML URL” and “XSL URL”.
² E.g. “cfdu = The path of the current file directory (URL)” and “CurrentFileURL = The path of the currently edited file (URL)”.

I have assigned this to myself, and given it a BUG label, but not a CONFIRMED label because I do not have a Windows system and thus cannot reproduce the error. But I do not plan on merging this until somebody who is not @daliboris reviews and verifies that it works properly on Windows. I haven’t assigned any other reviewers, though, because (in general) I do not know who has easy access to a Windows system to test.

Hi @daliboris — good to see you in Kraków!

I'm glad I was part of this nice event.

Hmmm … my oXygen (27.1) does not list ${cf} when I try to set up a new transformation scenario and click on the little “Insert Editor Variables” button (a yellow ellipsis under a green down-arrow).

Here are screenshots from my laptop copy of existing transformation scenario without any modifications:

Here is list of all available variables.

Does it work? I do not have any way to test it. I worry that the string-join(), because it is sticking a slash in between each member of the sequence, will return a string that starts with file://// instead of the desired file:/ or file:///. (I am not sure it would make a difference on a Windows system, though.)

You are right, it's my fault: the code adds extra slashes, but surprisingly local paths on my PC works also with these "extra" slashes.

This version returns the correct file URI:

<xsl:value-of select="string-join(('file://', if(matches($currentDirectory, '^[A-Z]:\\$')) 
              then  translate($currentDirectory, '\', '') else translate($currentDirectory, '\', '/'), $loc), '/')"/>

notes ¹ “XML URL” and “XSL URL”. ² E.g. “cfdu = The path of the current file directory (URL)” and “CurrentFileURL = The path of the currently edited file (URL)”.

Oh! So it is a parameter — and look at that, it is documented as a path, not a URL. I learned something new, thank you.

Do you want to commit the extra-slash-that-is-technically-incorrect-but-seems-to-work fix? If not, I think gitHub will actually let me commit something to your branch, but I am not 100% on that.

Windows path to URI functionality has now been fixed.

Thank you for your prompt cooperation.