28435 2015-04-08 09:57:07 +0000 [XT30TS] resolve-uri-022 2015-08-06 13:48:32 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Test Suite Working drafts PC Windows NT RESOLVED FIXED P2 normal --- 1 tim abel.online abel.braaksma mike public-qt-comments oldest_to_newest 119346 0 tim 2015-04-08 09:57:07 +0000 When run with an XSLT 2.0 processor, this test hits an error case since the template name "xsl:initial-template" is in a reserved namespace. 119539 1 abel.braaksma 2015-04-15 15:28:44 +0000 Oops, thanks! Fixed and pushed. 122340 2 mike 2015-07-31 10:54:56 +0000 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. 122479 3 abel.braaksma 2015-08-06 01:11:14 +0000 When writing this test I have tried to be careful to only test for RFC parts that are mandatory. Such things are, I believe: * base path with host name, but no trailing slash: slash must be appended, unless relative path is empty (5.4.3) * relative path with more ".." segments than in the base path, authority component remains, host and path must be separated by slash (5.2.4 and 5.4.2) * base path with dot-segments, after merging these must be removed (5.2.2 and 5.2.4) * 'overlapping' dotted segments, where removing dotted segments from right to left or left to right would yield different results. It should be from left to right (5.2.4) * relative part starting with "/" and followed by dotted segments: these have no effect, "/" remains in place (5.2.4) Most, if not all inspiration for this test comes from the examples in 5.4.1 and 5.4.2. I don't think any part of the RFC allows the resulting path segment to be a non-root path (i.e. without leading "/"), except for the case of an empty relative path and an empty path segment in the base path, but that is not covered by this test. 122493 4 mike 2015-08-06 13:48:32 +0000 I have decided to withdraw my objections to this test.