W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2005

Re: [F&O] fn:resolve-uri and non-hierarchical base URI

From: Colin Paul Adams <colin@colina.demon.co.uk>
Date: 09 Feb 2005 08:00:01 +0000
To: "Michael Kay" <mhk@mhk.me.uk>
Cc: "'Ashok Malhotra'" <ashok.malhotra@oracle.com>, "'K Karun'" <k.karun@oracle.com>, <public-qt-comments@w3.org>
Message-ID: <m31xbqxiwu.fsf@colina.demon.co.uk>

>>>>> "Michael" == Michael Kay <mhk@mhk.me.uk> writes:

    Ashok>  Rereading RFC 3986 it seems clear that relative URIs and
    Ashok> relative URI resolution works only for hierarchical URI
    Ashok> schemes.  It says ...
    Ashok> 
    Ashok> "Some URI schemes do not allow a hierarchical syntax matching
    Ashok> the <hier_part> syntax, and thus cannot use relative
    Ashok> references."
    Ashok> 
    Ashok> And, as Colin points out, the base URI needs to be an absolute
    Ashok> URI.
    Ashok> 
    Ashok> Thus, it seems to me that all we need to change in
    Ashok> fn:resolve-URI is to add the sentence from RFC 3986 quoted
    Ashok> above.

    Michael> Yes: the new RFC does seem to lead us in this direction.

    Michael> However, URIs are a minefield and we need to tread
    Michael> carefully. For example, when resolving R against B, if R
    Michael> is an absolute URI the result should be R, and the value
    Michael> of B should be ignored.

That is already covered by the definition of fn:resolve-uri

    Michael> Another problem: although the RFC says that URI
    Michael> resolution only makes sense for hierarchical URIs, it
    Michael> doesn't make it clear how one decides whether a given URI
    Michael> is hierarchical. This seems to be a property of the URI
    Michael> scheme, not a property of the URI itself, and new URI
    Michael> schemes of course can be invented over time.

It's hierarchical if it doesn't have path-rootless (formerly opaque-part).
So if the base-uri matches scheme:path-rootless, and the uri to
resolve is relative, resolution can only return an absolute URI by
returning the base URI. Whether fn:resolve-uri should do this, or
return an error, is for the WG to decide, I think.

    Michael> I think we also need some clarification at the data model
    Michael> level (and indeed in the xml:base specification). There
    Michael> is currently nothing in the data model, or the infoset,
    Michael> or XML base, that says that the base URI of a node must
    Michael> be an absolute and/or hierarchic URI. If we believe that
    Michael> resolving a relative URI only makes sense against an
    Michael> absolute hierarchic URI then we need to ensure that the
    Michael> base URI of a node is always in this form.

That's not necessary, or possible.
For proof of impossibility, suppose a source document includes
an xm:base value of "urn:a:b:c" on one of it's elements. This is a
path-rootless URI.

    Michael> I think the intent of the XML Base specification is that
    Michael> the value of the xml:base attribute can be a relative
    Michael> URI, and the [base URI] property of the node is then
    Michael> obtained by resolving this relative URI against the [base
    Michael> URI] of its parent element (or of the document entity or
    Michael> external entity in which it appears). (The intent is
    Michael> clear from the example in section 3 of XML Base, but
    Michael> there is no text to back it up).

It is clear, I think. There is nothing that says that the xml:base
attribute value must be absolute, therefore it can be relative.
But the infoset says that the [bas URI] property is determined
according to XML Base, and this says that the base URI of an element
is the value of the xml:base attribute if it is present. so this
property can be a relative URI that needs resolving.

Now fn:resolve-uri (first form) uses the base URI property from the
static context, which is defined to be an absolute URI. So the problem
reduces to ensuring the static context Base URi is absolute, which can
be solved by resolving the Base URI property of an element when the
static context is constructed against that element.
-- 
Colin Paul Adams
Preston Lancashire
Received on Wednesday, 9 February 2005 08:00:42 UTC

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