Re: More test cases to be confirmed

Dan,

I think cases (1) and (2) are sanctioned as given by the latest spec.

The rest, of course, are up for debate.  I now have an implementation that 
handles all the cases as I suggest is more consistent (including an 
absolute-to-relative function that round-trips per [1]).

#g
--

[1] http://lists.w3.org/Archives/Public/uri/2003Jan/0005.html

At 17:37 19/02/04 -0600, you wrote:
>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?

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Thursday, 19 February 2004 18:57:07 UTC