I believe that
may also be a possible expected result.
OK. The LEIRI spec says spaces SHOULD NOT be %-encoded, but it doesn't say MUST NOT, so I will allow this result.
Thanks. Are you basing you response on the text
"Conversion from a LEIRI to an IRI or a URI must be performed only when absolutely necessary and as late as possible in a processing chain. In particular, neither the process of converting a relative LEIRI to an absolute one nor the process of passing a LEIRI to a process or software component responsible for dereferencing it should trigger percent-encoding."
or something else?
Yes, that's the text I was relying on. Given that we are dealing with a relative LEIRI that is not an IRI, the advice
the process of converting a relative LEIRI to an absolute one ... should [not] trigger percent-encoding
seems to cover this situation rather precisely.
Confirmed fixed. Thanks.
I'd argue that because resolve-uri returns a new URI, the implementation is at liberty to return a URI, IRI or LEIRI regardless of the input. Perhaps this could be clarified in the specification? It's not _just_ converting from a relative to an absolute URI.
I'm re-opening this as a spec bug, because the final comment suggests that clarifications to the spec are needed. Also, the agreed resolution for this test contradicts the expected result of various XSLT tests including type-functions-0304 and resolve-uri-022, and I don't want to argue for a change to those tests unless and until the spec is clarified.
The spec for resolve-uri currently says
The function resolves the relative IRI reference $relative against the base IRI $base using the algorithm defined in [RFC 3986], adapted by treating any ·character· that would not be valid in an RFC3986 URI or relative reference in the same way that RFC3986 treats unreserved characters. No percent-encoding takes place.
This seems to unequivocally say that if there is a space in the input, and if the implementation chooses to accept this (as a LEIRI), then there must be a space in the output, not a "%20". The argument in this bugzilla thread that LEIRI permits escaping seems vacuous, because the resolve-uri() spec does not reference LEIRI for how relative URI resolution is performed. Perhaps it should.