W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2003

RE: [F&O] 11.1, 7.3, 15.4.4, and 15.4.5

From: Paul Cotton <pcotton@microsoft.com>
Date: Wed, 14 May 2003 12:11:54 -0400
Message-ID: <E7AC4500EAB7A442ABA7521D1881439706324DD3@tor-msg-01.northamerica.corp.microsoft.com>
To: "Kian-Tat Lim" <ktl@ktlim.com>
Cc: <public-qt-comments@w3.org>

> [A formal comment, since no one seems to have paid
attention to my previous message on this topic.]

If your previous message is in

then it only arrived yesterday! 

The XML Query and XSL WGs are meeting F2F this week and while we did
process a lot of public Last Call comments at a meeting on Tuesday we
did not get to your comment since it arrived during our meeting.   You
should not assume that we have "not paid attention" to your message.  We
will certainly get to it.

Thank you for your follow up.

Chair, XML Query WG
Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 


> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Kian-Tat Lim
> Sent: May 14, 2003 11:54 AM
> To: public-qt-comments@w3.org
> Subject: [F&O] 11.1, 7.3, 15.4.4, and 15.4.5
> [A formal comment, since no one seems to have paid
> attention to my previous message on this topic.]
> Section 11.1 of "XQuery 1.0 and XPath 2.0 Functions
> and Operators" (F&O), describing fn:resolve-uri,
> states that the function "resolves the relative URI
> $relative against the base-uri $base and returns
> the resulting absolute URI".  It does not give
> an algorithm for doing so.  Since RFC 2396 is
> cited as a normative reference in section A.1,
> it would seem that the algorithm given there in
> section 5.2, "Resolving Relative References to
> Absolute Form", is the appropriate one for executing
> this function.
> That algorithm states, in part:
> For each URI reference, the following steps are performed in order:
>     1) The URI reference is parsed into the potential four
>        components and fragment identifier, as described in
>        Section 4.3.
>     2) If the path component is empty and the scheme, authority, and
>        query components are undefined, then it is a reference to the
>        current document and we are done.  Otherwise, [...]
> In Appendix C of that RFC, "Examples of Resolving Relative
> URI References", Section C.2, "Abnormal Examples", states
> explicitly:
>      An empty reference refers to the start of the current document.
>           <>            =  (current document)
> Both of these appear to be in conflict with the last paragraph
> of F&O section 11.1 (before the Note), which states:
>     If the $relativeURI is the zero-length string, returns the
>     value of the base-uri property from the static context in
>     the first form and $base in the second form.
> Section 2.1.1 of "XML Path Language (XPath) 2.0" does not
> provide for the current document's URI in the static
> context, only an environment-specified base URI.
> There appear to be two alternatives:
> 1) Add text to section 11.1 stating that the URI resolution
> algorithm to be used differs from that in RFC 2396 in the
> case of a zero-length string $relativeURI, and that the
> base URI is the result instead of the current document's
> URI.
> 2) Add the current document URI, when available, to the
> static context and return it instead of the base URI if
> $relativeURI is the zero-length string.
> In either case, additional text highlighting the
> zero-length relative URI string case should be added to
> sections 7.3, 15.4.4, and 15.4.5, which each mention
> resolution of relative URIs with respect to base URIs.
> Finally, a typo: section 15.4.4 of F&O specifies
> "fn:doc($uri as xs:string?) as document?", but its
> third paragraph begins "If $srcval is the empty
> sequence".  This should be replaced with "If $uri
> is the empty sequence".
> --
> Kian-Tat Lim, ktl@ktlim.com, UTF-7: +Z5de+pBU-
Received on Wednesday, 14 May 2003 12:14:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:12 UTC