More test cases to be confirmed

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