- From: <nobody@w3.org>
- Date: Fri, 31 Jul 2015 10:54:56 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28435 Michael Kay <mike@saxonica.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |mike@saxonica.com Resolution|FIXED |--- --- Comment #2 from Michael Kay <mike@saxonica.com> --- This test is basically a torture-test of edge cases in the RFC 3986 specification, especially the rules for removal of /./ and /../ segments in the URI. It seems that the Java implementation, which Saxon relies on, produces different results in many cases. I would like to try and establish in which cases these variations are actually acceptable. Given the rather casual language of the spec, this isn't easy. However, there are comments in the test like <!-- variants of trying to get past the root, should return root path acc. to RFC, and *must* include root path leading "/" --> where the author of the test appears to have taken a view that some provisions in the RFC are mandatory, and others are only recommendations. Note that the spec for resolve-uri() explicitly states that where the RFC permits variations, so does resolve-uri(). I think we should start by making sure that the test doesn't mandate particular results for some of these edge cases in situations where the RFC allows flexibility. The language of the RFC is complex. It doesn't use simple "may", "must", and "should". It will sometimes describe a particular behaviour as common in practice, but erroneous. These are muddy waters, and I think we should allow implementations the benefit of the doubt where necessary. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 31 July 2015 10:54:59 UTC