- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 25 Jan 2010 09:49:52 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8810
Summary: [F+O 1.1] resolve-uri() and the various RFCs
Product: XPath / XQuery / XSLT
Version: Working drafts
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: Functions and Operators 1.1
AssignedTo: mike@saxonica.com
ReportedBy: mike@saxonica.com
QAContact: public-qt-comments@w3.org
In the current 1.0/2.0 specification (including in particular erratum FO.E1)
- fn:resolve-uri() says you can use either RFC 2396 or RFC 3986
- In XSLT 2.0, document() says you must use 3986
- fn:doc() just says you resolve the URI, without further elaboration.
I propose that in 1.1/2.1:
- fn:resolve-uri() should point to RFC 3986 only, and use more prescriptive
wording: change "using an algorithm such as those described in [RFC 2396] or
[RFC 3986]" to "using the algorithm described in section 5.2 of [RFC 3986]",
but retain (mutatis mutandis) the Note that says "The algorithm in the cited
RFC includes some variations that are optional or recommended rather than
mandatory; it also describes some common practices that are not recommended,
but which are permitted for backwards compatibility. Where the cited RFC
permits variations in behavior, so does this specification."
- all other places where we talk about resolving relative URIs should point to
rn:resolve-uri().
A particular technical issue with RFC 2396 is the handling of the relative URI
"". RFC 2396 in section 4.2 is clear that this is a "same-document reference",
but the URI resolution algorithm in section 5.2 does not treat it as such: the
algorithm given relative="", base="http://example.com/dir" returns
"http://example.com/". This is fixed in the algorithm given in section 5.2 of
RFC 3986.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 25 January 2010 09:49:53 UTC