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

More test cases to be confirmed

From: Graham Klyne <gk@ninebynine.org>
Date: Thu, 19 Feb 2004 15:00:26 +0000
Message-Id: <5.1.0.14.2.20040219145229.00b8c838@127.0.0.1>
To: <uri@w3.org>

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"

(2)
Base:   "foo:a"
Ref:    "b/c"
Result: "foo: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)

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
Received on Thursday, 19 February 2004 13:39:29 UTC

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