- From: David Birnbaum <djbpitt@gmail.com>
- Date: Sun, 22 Nov 2020 11:34:36 -0500
- To: XProc Dev <xproc-dev@w3.org>
- Message-ID: <CAP4v81o3kyQs3yGXWX4rdGpUi7ExpKBjfDzXhqCbbnnZMfHh7g@mail.gmail.com>
Dear XProc Dev, I've been struggling with filenames that are not compatible with URIs, and attempting to work around the limitation by using encode-for-uri() when I save the file. I described the general problem on the eXist-open mailing list, so I won't repeat it here, but my issue has an XProc aspect, and may even be an XProc—rather than broader filename—issue, and I would be grateful if someone on this list to help clarify that aspect of it for me. Here is a test XProc file, which I run under MorganaXProc-IIIse 0.9.4.8-beta: <?xml version="1.0" encoding="UTF-8"?> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:c=" http://www.w3.org/ns/xproc-step" version="3.0"> <p:input port="source"> <p:inline> <doc>Hello world!</doc> </p:inline> </p:input> <p:output port="result"/> <p:variable name="output-filename" select="encode-for-uri('test-1a%7%.xml')"/> <p:identity message="{$output-filename}"/> <p:store href="{$output-filename}"/> <p:identity/> </p:declare-step> Because the percent signs as they are used in the filename are incompatible with URI encoding, I expect them to be percent-encoded themselves, with the modified filename echoed to stderr (in the <p:identity> step) and used to save the test file (in the <p:store> step). What happens instead is that the percent encoded value is written, as expected, to stderr: test-1a%257%25.xml but the file is saved to the local filesystem as if encode-for-uri() had not been applied, that is, as: test-1a%7%.xml What I expected instead is that the filename used to save the output to the local filesystem would match the percent-encoded value displayed in the <p:identity> step. For what it's worth, if I run encode-for-uri() twice (nested) on the filename, the stderr result is twice percent-encoded (test-1a%25257%2525.xml) and the filename as written by the <p:store> step is singly percent-encoded (test-1a%257%25.xml). This all seems to suggest that 1) encode-for-uri() works, and 2) it is possible to use the output of an encode-for-uri() call to create a filename. But it looks as if the filename as used by the <p:store> step undoes one instance of encode-for-uri()—the only instance in the example above and the second (wrapping) instance in the "for what it's worth" experiment below that. What I expected was that the filename used by <p:store> would be the same as the value specified for the @href attribute and written to stderr in the <p:identity> step. Have I misunderstood how <p:store> works with filenames? Sincerely, David
Received on Sunday, 22 November 2020 16:35:01 UTC