- 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