W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > April to June 2002

RE: Resolving references against base URIs

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 15 Apr 2002 10:17:26 -0400 (EDT)
Message-Id: <200204151415.KAA2425703@smtp2.mail.iamworld.net>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>
Cc: <www-xml-linking-comments@w3.org>, <uri@w3.org>
At 09:15 AM 2002-04-15 , Jeremy Carroll wrote:
>Summary:
>
>RDF Core's interpretation of same-document references within RFC 2396 is
>legitimate.
>And even if it isn't, it is a legitimate interpretation of a same-document
>reference within an RDF document!
>

The bad news:

In fact, "the same document" in fragment-only relative references should be taken even more locally and particularly than "the URI from which this representation was recovered."  The latter reading is inadequate, an error.  It should be read as "this representation."  So the type is known, and with it the semantics of #fragment references.  Without recourse to _even_ the URI from which it was recovered.  As Paul suggested.  For hyperlinks with goTo semantics, where the absolute URI equivalent of the reference is unnecessary, it is moot and therefore not defined.  The best available absolute reference (nearest to equivalent) would be base-ified using the URI from which this representation was recovered, but that question has no need and no standing in the case of following hyperlinks in browsing the same "recovered representation."  There is no general answer, absent a universal document type (see next).

The good news:

The semantics of #fragment in "the current document" is governed by the _type_ of the recovered represetation of the URI accessed.  So for RDF to apply the semantic constraint that a #fragment reference is equivalent to a given absolute URI -- within a representation which belongs to a type which by its type definition is bound to the constraints of the RDF model -- is entirely within the purview of the specification of the RDF model and the languages in which it is represented.

This violates the universality goal that any URI-reference can be used in any place a URI-reference can be used, but that is a different matter.  This is also violated by having some references take anyURI and others limited to IDREF in the same document.  The RDF restriction to absolute-URI-reference senses for fragment-URI-reference signs does not violate RFC-2396, at least.  This is just that the RDF model only admits of 'absolute' references.  So references in any syntax binding of the RDF model will only contain 'absolute' URI-references.

That should give you what you need.

Just don't try to assume this for search URLs in the http: scheme unless the search service replies with a representation in an RDF model-conforming document type.

Al

>
>
>Jeremy:
>> > e,f,i,j,k,l
>> > Base does apply to same document references in RDF/XML
>Stuart:
>> I think that you're changing the semantics of URI references as defined in
>> RFC2396, particularly section 4.2, same document references. I think your

>> answers would be correct only for those cases where the in-scope base URI
>> and the URI from which the document were retrieved are the same.
>
>
>Stuart's point of view was expressed clearly (and repeatedly) to the RDF
>Core WG during the decision process e.g. issue #1 in
>
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0516.html
>
>
>Jeremy:
>> The positive tests on the test cases web site show a usage of xml:base
>> in RDF/XML and the resolution of that usage in terms of the RDF graph
>> produced (with absolute URI ref labels).
>
>Paul:
>>  It is important that RDF and everyone
>> else realize that use of XML Base requires compliance with RFC 2396 which
>> requires that relative URI references consisting of just the fragment id
>> ignore any base URI and instead always refer to a fragment id within the
>> current document.
>
>
>I do not  recall the RDF Core WG having resolved a justification of the
>decision in favour of the these test cases. Hence I will give my own
>justification.
>
>First:
>The actual decisions of the RDF Core WG reflect what 'same document
>references' mean within an RDF/XML document within the scope of an xml:base
>attribute. Primarily the WG decisions reflect the meaning of RDF/XML rather
>than XML Base of RFC 2396. However, these decisions do point to weaknesses
>in RFC 2396.
>The RDF Core WG has consistently (with or without xml:base) interpreted all
>uri references as absolute uri references. The decisions clarify that when
>the normal uri resolution mechanisms deliver a same document reference, we
>form the absolute uri ref using the currently in scope xml:base uri.
>
>
>Second:
>
>The definition of same-document references is unfortunately focussed on
>browsing:
>
>[[[
>4.2. Same-document References
>
>1 A URI reference that does not contain a URI is a reference to the
>2 current document.  In other words, an empty URI reference within a
>3 document is interpreted as a reference to the start of that document,
>4 and a reference containing only a fragment identifier is a reference
>5 to the identified fragment of that document.  Traversal of such a
>6 reference should not result in an additional retrieval action.
>7 However, if the URI reference occurs in a context that is always
>8 intended to result in a new request, as in the case of HTML's FORM
>9 element, then an empty URI reference represents the base URI of the
>0 current document and should be replaced by that URI when transformed
>1 into a request.
>]]]
>
>line 3 "start of that document" is meaningless for an RDF document. RDF is a
>graph and is not a linear structure.

>
>line 6 "no additional retrieval action" All URIrefs in RDF are absolute, and
>none are retrieved accept when the application content "is always intended
>to result in a new request".
>The RDF Core is trying to clarify which absolute URI ref corresponds to a
>same document ref.
>
>line 9 The answer, at least for empty same document refs, it is the "base
>URI".
>
>We discover what a base URI is in section "5.1 Establishing a Base URI"
>
>
>[[[
>5.1. Establishing a Base URI
>
>   The term "relative URI" implies that there exists some absolute "base
>   URI" against which the relative reference is applied.  Indeed, the
>   base URI is necessary to define the semantics of any relative URI
>   reference; without it, a relative reference is meaningless.  In order
>   for relative URI to be usable within a document, the base URI of that
>   document must be known to the parser.
>]]]
>
>I note that the algorithm in
>5.2. Resolving Relative References to Absolute Form
>amongst its defects, does not implement line 9 of section 4.2.
>
>Once we are dynamically changing the xml:base from one element to the next,
>we are outside the design bounds of RFC 2396.
>
>If we consider only documents with a single xml:base on their outermost
>elements, then as far as RDF goes, the resolution of the same document test
>cases is consistent with section 4.2 of RFC 2396.  A same document
>reference, like any uri ref, in an RDF file means an absolute URI ref. The
>absolute URI ref is formed by taking "the base URI" of the document, as
>suggested in line 9 of 4.2. The fragment part if taken from the same
>document reference.
>
>Jeremy
>
>
>
>
>> > EASY:
>> > a "http://example.org/dir/file"      "../relfile"
>> > b "http://example.org/dir/file"      "/absfile"
>> > c "http://example.org/dir/file"      "//another.example.org/absfile"
>> >
>> > GETTING HARDER:
>> > d "http://example.org/dir/file"      "../../../relfile"
>> > e "http://example.org/dir/file"      ""
>> > f "http://example.org/dir/file"      "#frag"
>> >
>> > MASTER CLASS:
>> > g "http://example.org"               "relfile"
>> >
>> > h "http://example.org/dir/file#frag" "relfile"
>> > i "http://example.org/dir/file#frag" "#foo"
>> > j "http://example.org/dir/file#frag" ""
>> >
>> > k "mailto:Jeremy_Carroll@hp.com"     "#foo"
>> > l "mailto:Jeremy_Carroll@hp.com"     ""
>> > m "mailto:Jeremy_Carroll@hp.com"     "relfile"
> 
Received on Monday, 15 April 2002 10:28:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:43 GMT