W3C home > Mailing lists > Public > xproc-dev@w3.org > November 2020

encode-for-uri() and filenames?

From: David Birnbaum <djbpitt@gmail.com>
Date: Sun, 22 Nov 2020 11:34:36 -0500
Message-ID: <CAP4v81o3kyQs3yGXWX4rdGpUi7ExpKBjfDzXhqCbbnnZMfHh7g@mail.gmail.com>
To: XProc Dev <xproc-dev@w3.org>
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

<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="
  <p:input port="source">
      <doc>Hello world!</doc>
  <p:output port="result"/>
  <p:variable name="output-filename"
  <p:identity message="{$output-filename}"/>
  <p:store href="{$output-filename}"/>

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:


but the file is saved to the local filesystem as if encode-for-uri() had
not been applied, that is, as:


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?


Received on Sunday, 22 November 2020 16:35:01 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 22 November 2020 16:35:02 UTC