W3C home > Mailing lists > Public > uri@w3.org > February 2004

Re: More test cases to be confirmed

From: Dan Connolly <connolly@w3.org>
Date: Thu, 19 Feb 2004 17:37:51 -0600
To: Graham Klyne <gk@ninebynine.org>
Cc: uri@w3.org
Message-Id: <1077233871.29429.5256.camel@dirk>

I can't confirm these... I plugged them into
  http://www.w3.org/2000/10/swap/uripath.py
  v 1.15 2004/01/28 22:22:10

and it says, basically, "don't do that!"

Some details below...

On Thu, 2004-02-19 at 09:00, Graham Klyne wrote:
> More questions arising from my implementation work...
> 
> I have a revised parser based on the revised spec, except for some details 
> of dot-segment normalization, that passes a pretty wide range of test 
> cases.  Currently, with respect to the queries below, I do "what I would 
> expect" rather than what the spec. currently says.
> 
> ...
> 
> (1)
> Base:   "http://example.com/path?query#frag"
> Ref:    ""   (empty URI)
> Result: "http://example.com/path?query"

AssertionError: Base may not contain hash:
'http://example.com/path?query#frag'

> (2)
> Base:   "foo:a"
> Ref:    "b/c"
> Result: "foo:b/c"

ValueError: Base <foo:a> has no slash after colon - with relative 'b/c'.

> 
> (3)
> Although it's a marginal case, I find myself in disagreement with the way 
> the current spec seems to treat this case:
> 
> Base:   "foo:a"
> Ref:    "../b/c"
> Result: "foo:/b/c"
> (based on bullet 2 of section 5.2.4)

ValueError: Base <foo:a> has no slash after colon - with relative
'../b/c'.


> I think it would be more consistent (and it's also what software I wrote in 
> the past does) in this case to return:
> 
> Result: "foo:../b/c"
> 
> My argument about this being more consistent is based on the fact that it 
> seems fine in other cases for the result to be a relative URI; e.g.
> 
> Base:   foo:a/b
> Ref:    c/d
> Result: a/c/b
> 
> so why not when the leading segment happens to be '../'?
> 
> (4)
> Base:   "foo:a"
> Ref:    "./b/c"
> Result: "foo:b/c"
> 
> This is not strictly according to RFC2396bis, which I think would have the 
> value returned be:
> 
> Result: "foo:/b/c"
> 
> I think "./b/c" should be treated as equivalent to "b/c", hence the result 
> returned should be the same as test case (2) above.
> 
> (5)
> Base:   "foo://a//b/c"
> Ref:    "../../d
> Result: "foo://a/d"
> 
> (6)
> Base:   "http://a/b/c/d;p?q"
> Ref:    "/../g"
> Result: "http://a/g"     (according to spec)
> Result: "http://a/../g"  (what I'd expect, see above)
> 
> #g
> 
> 
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you at the W3C Tech Plenary in Cannes 1-5 Mar 2003?
Received on Thursday, 19 February 2004 18:37:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC