Bug 20602 - [QT3TS] fn-resolve-uri-32
Summary: [QT3TS] fn-resolve-uri-32
Status: REOPENED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20672
  Show dependency treegraph
 
Reported: 2013-01-08 16:29 UTC by Tim Mills
Modified: 2015-07-31 10:01 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mills 2013-01-08 16:29:08 UTC
I believe that 

  <assert-string-value>http://www.example.com/this%20doc.html</assert-string-value>

may also be a possible expected result.
Comment 1 Michael Kay 2013-01-08 18:54:57 UTC
OK. The LEIRI spec says spaces SHOULD NOT be %-encoded, but it doesn't say MUST NOT, so I will allow this result.
Comment 2 Tim Mills 2013-01-08 21:45:57 UTC
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?
Comment 3 Michael Kay 2013-01-08 22:26:28 UTC
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.
Comment 4 Tim Mills 2013-01-10 10:31:00 UTC
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.
Comment 5 Michael Kay 2015-07-31 09:54:12 UTC
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 

<quote>
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.
</quote>

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.