8810 2010-01-25 09:49:51 +0000 [FO 1.1] resolve-uri() and the various RFCs 2010-12-10 17:44:38 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.0 Working drafts PC Windows NT CLOSED FIXED P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 31192 0 mike 2010-01-25 09:49:51 +0000 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. 31672 1 mike 2010-02-09 17:03:43 +0000 2010-02-09 - proposal accepted in principle, action on MHK to identify in detail the places that need to be changed. 32763 2 mike 2010-03-02 16:00:08 +0000 First point: there's a contradiction here. In XSLT and XQuery, when we have to resolve a URI, we generally handle "wannabe URIs" according to the rules in XLink: that is, the URI is first percent-encoded to make it a valid RFC 3986 URI, then the URI resolution algorithm in the RFC is applied. The current spec for resolve-uri() does not do this (it rejects wannabe-URIs with an error). I propose that resolve-uri() should be changed to apply the escaping where needed. Then the change to resolve-uri() is proposed as follows: (0) Add phrasing to the effect: "The URI references must conform to the same rules as the locator attribute (href) defined in section 5.4 of [XLink]; if necessary to make them valid according to RFC 3986, they are first percent-encoded." (Need to check the new XLink draft here). (1) change "If $relative is a relative URI reference, it is resolved against $base, or against the base-uri property from the static context, using an algorithm such as those described in [RFC 2396] or [RFC 3986], and the resulting absolute URI reference is returned." to "If $relative is a relative URI reference, it is resolved against $base, or against the base-uri property from the static context, using the algorithm described in [RFC 3986], and the resulting absolute URI reference is returned." (2) change the second note "The algorithms in the cited RFCs..." accordingly. Second, several specs (XQuery, XSLT, F+O) make frequent reference to "resolving" a URI. These references can easily be found by searching (but take care, because the word is also used in other senses, e.g. resolving a namespace prefix). I propose that each of these specs contains the definition: [DEFINITION: to *resolve* a relative URI is to expand it to an absolute URI, by reference to a base URI, as if by calling the function fn:resolve-uri.] and that appropriate uses of the term resolve should be linked to this definition. The definition can go in 2.4.5 URI Literals for XQuery, in 6 Functions that manipulate URIs for F+O, and in 5.8 URI References for XSLT. 43261 3 mike 2010-12-10 17:44:23 +0000 The proposal in comment #2 was accepted on 2010-05-14