This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30316 - [FO31] percent encoding rules in F&O for fn:resolve-uri are opposite to the same rules in XP31
Summary: [FO31] percent encoding rules in F&O for fn:resolve-uri are opposite to the s...
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 major
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:
 
Reported: 2018-11-07 19:36 UTC by Abel Braaksma
Modified: 2018-11-07 19:36 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2018-11-07 19:36:54 UTC 
In F&O 3.1 we say "No percent encoding takes place" under the section of fn:resolve-uri.

In the XPath 3.1 spec, we say under "2.4.6 Resolving a Relative URI Reference":

"Any process that attempts to resolve URI against a base URI, or to dereference the URI, may apply percent-encoding or decoding as defined in the relevant RFCs. "


Apart from the type ("resolve *a* URI"), this rule appears to be opposite to the one under fn:resolve-uri. Even more so, because sections that involve resolving URIs often point to either location.

Furthermore: test-case 'fn-resolve-uri-31' explicitly tests that no percent decoding should take place.

Both rules, same wording, were also present in XP30 and FO30.

The question now is: which rule has prevalence? May processors apply percent-de-/encoding? From relevant discussions I think the answer should be a resounding "NO", but since both specs have REC status, I don't know what the policy is here. Disallowing it could break existing processors. Allowing it wouldn't break anything, because of the "MAY".

Since resolving URIs is essentially everywhere, I marked the bug "major".