W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2015

[Bug 20602] [QT3TS] fn-resolve-uri-32

From: <nobody@w3.org>
Date: Fri, 31 Jul 2015 09:54:12 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-20602-523-RRZsLwVCC1@http.www.w3.org/Bugs/Public/>

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
             Status|CLOSED                      |REOPENED
          Component|XQuery 3 & XPath 3 Test     |Functions and Operators 3.1
                   |Suite                       |
         Resolution|FIXED                       |---
           Assignee|oneil@saxonica.com          |mike@saxonica.com

--- Comment #5 from Michael Kay <mike@saxonica.com> ---
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

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 31 July 2015 09:54:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:55 UTC