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

RE: Resolving references against base URIs

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 11 Apr 2002 10:47:53 -0400 (EDT)
Message-ID: <5E13A1874524D411A876006008CD059F192AAD@0-mail-1.hpl.hp.com>
To: "'Jeremy Carroll'" <jjc@hplb.hpl.hp.com>
Cc: www-xml-linking-comments@w3.org, uri@w3.org
Hi Jeremy,

Hmmm....

> e,f,i,j,k,l
> Base does apply to same document references in RDF/XML

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.

Regards

Stuart
--
> -----Original Message-----
> From: Jeremy Carroll [mailto:jjc@hplb.hpl.hp.com]
> Sent: 10 April 2002 18:43
> To: uri@w3.org
> Cc: www-xml-linking-comments@w3.org
> Subject: Resolving references against base URIs
> 
> 
> 
> This is a comment about RFC 2396 that I have been actioned to 
> send on behalf
> of the W3C RDF Core Working Group [1]
> 
> The key issue concern resolving same document references 
> and/or resolving
> against non-hierarchical URIs.
> 
> These have been causing us difficulty in using xml:base
> 
> As one of our deliverables we produce test cases [2].
> 
> A summary table of our URI resolution problems is as follows;
> the answers we have agreed are in the attached HTML file.
> 
> 
> 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"
> 
> 
> We have reached consensus on and approved all these tests 
> except for the
> last which some of us consider an error and others resolve as 
> indicated in
> the html file.
> 
> The rationales for our views are approximately as follows:
> 
> d "http://example.org/dir/file"      "../../../relfile"
> 
> [[[RFC2396
>    In practice, some implementations strip leading relative symbolic
>    elements (".", "..") after applying a relative URI 
> calculation, based
>    on the theory that compensating for obvious author errors is better
>    than allowing the request to fail.
> ]]]
> Not permitted in RDF/XML.
> 
> e,f,i,j,k,l
> Base does apply to same document references in RDF/XML
> 
> g
> Failure to insert / is a bug with RFC 2396
> 
> h,i,j
> Strip frag id from base uri ref before resolving.
> Notice j is particularly surprising.
> 
> k,l
> Same document reference resolution even works for 
> non-hierarchical uris.
> 
> m
> - no consensus
> 
> 
> The test suite is structured as follows:
> 
> 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). Each test consists of two 
> files, an RDF/XML
> document and an n-triple file (substitute .rdf with .nt in 
> the URL), being a
> list of the edges of the graph.
> 
> The negative test case shows possibly illegal usage of 
> xml:base in RDF/XML.
> 
> 
> Our intent is that these tests will be part of a normative 
> revision of the
> RDF recommendation.
> 
> Jeremy Carroll
> HP Rep W3C RDF Core WG
> 
> 
> 
> [1]
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Apr/0008.html
> 2002-03-22#4:  jeremy Send mailto:uri@w3.org with appropriate tests
> 
> [2]
> http://www.w3.org/2000/10/rdf-tests/rdfcore/xmlbase/
> 
> 
Received on Monday, 15 April 2002 06:57:32 GMT

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