I have re-implemented the URI parser in Network.URI using Parsec rather than the regex library that isn't available in Hugs, and I've wired the result into part of my URI handling test suite. The parser is based on the very latest work-in progress that is intended to replace RFC 2396 (see source code for refs). The parsing is completely rewritten, and passes all my test cases. The relative URI calculation ("relativeTo") is still the original code, and I'm noting some discrepancies with my test suite (see below). There are some more discrepancies with test cases from RFC2396, that I haven't yet looked into. The source file and test suite can be found here: http://www.ninebynine.org/Software/HaskellUtils/Network/ It is not complete, but I'm hoping I have enough working to get the HXML toolbox running under Hugs/Windows. If there is any interest in adopting this as a more portable replacement for the current Network.URI module, I'll look into bringing it fully into line with the test suite. #g -- Test results: [[ ### Failure in: Test Relative URIs:20:1 testRelative21(abs) expected: "file:/ex/x/q/r#" but got: "file:/ex/x/q/r" ### Failure in: Test Relative URIs:30:1 testRelative31(abs) expected: "file:/some/dir/#" but got: "file:/some/dir/" ### Failure in: Test Relative URIs:36:1 testRelative37(abs) expected: "mailto:local/qual@domain.org#frag" but got: "mailto:local/local/qual@domain.org#frag" ### Failure in: Test Relative URIs:45:1 testRelative50(abs) expected: "http://example/a/b/../../c" but got: "http://example/c" ### Failure in: Test Relative URIs:46:1 testRelative51(abs) expected: "http://example/a/b/c/../../" but got: "http://example/a/" ### Failure in: Test Relative URIs:47:1 testRelative52(abs) expected: "http://example/a/b/c/./" but got: "http://example/a/b/c/" ### Failure in: Test Relative URIs:48:1 testRelative53(abs) expected: "http://example/a/b/c/.././" but got: "http://example/a/b/" ### Failure in: Test Relative URIs:49:1 testRelative54(abs) expected: "http://example/a/b/c/d/../../../../e" but got: "http://example/e" ### Failure in: Test Relative URIs:50:1 testRelative55(abs) expected: "http://example/a/b/c/d/../.././../../e" but got: "http://example/e" ### Failure in: Test Relative URIs:62 testRelative76 expected: "mid:m2@example.ord/c2@example.org" but got: "mid:m@example.ord/m2@example.ord/c2@example.org" Cases: 120 Tried: 120 Errors: 0 Failures: 10 ]] The relevant test cases are, stated as: [test-name: base-uri expected-absuri relative-uri] ... [testRelative21: "file:/ex/x/y" "file:/ex/x/q/r#" "q/r#"] (but got: "file:/ex/x/q/r") In this case, the empty fragment has been incorrectly discarded -- I think this may be a bug in 'uriToString' ... [testRelative31: "file:/some/dir/foo" "file:/some/dir/#" "./#" (similar problem) ... [testRelative37: "mailto:local/qual@domain.org" "mailto:local/qual@domain.org#frag" "local/qual@domain.org#frag"] (but got: "mailto:local/local/qual@domain.org#frag") In this case, it appears that relative path processing is being applied incorrectly to a non-hierarchical base URI. ... [testRelative50: "ftp://example/x/y" "http://example/a/b/../../c" "http://example/c"] [testRelative51: "ftp://example/x/y" "http://example/a/b/c/../../" "http://example/a/"] [testRelative52: "ftp://example/x/y" "http://example/a/b/c/./" "http://example/a/b/c/"] [testRelative53: "ftp://example/x/y" "http://example/a/b/c/.././" "http://example/a/b/"] [testRelative54: "ftp://example/x/y" "http://example/a/b/c/d/../../../../e" "http://example/e"] [testRelative55: "ftp://example/x/y" "http://example/a/b/c/d/../.././../../e" "http://example/e"] These exercise some URI path-normalization code that I have in my original implementation. As far as I can tell, these are not problems with the GHC implementation. ... [testRelative76: "mid:m@example.ord/c@example.org" "m2@example.ord/c2@example.org" "mid:m2@example.ord/c2@example.org"] (but got: "mid:m@example.ord/m2@example.ord/c2@example.org") This looks like another case of inappropriate relative path processing. ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact