29405 2016-01-29 23:46:32 +0000 [QT3] K-CodepointToStringFunc-8 2016-04-29 08:21:08 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC Linux CLOSED FIXED P2 normal --- 1 benito oneil abel.braaksma josh.spiegel mike tim public-qt-comments oldest_to_newest 124747 0 benito 2016-01-29 23:46:32 +0000 The test K-CodepointToStringFunc-8 calls codepoints-to-string(8) and accepts <assert-string-value>&amp;#x8;</assert-string-value> But that string seems doubly escaped. &#x8; alone would escape a single 8 codepoint character 124748 1 abel.braaksma 2016-01-30 01:51:32 +0000 I agree that the assert-string-value is incorrect and since the XML document containing the test is XML 1.0 it cannot be made correct. I think the test should probably be split in two: 1) one with an XML 1.1 dependency with an XPath test like string-to-codepoints(.) = 8, or a serialization-matches test. 2) and one without the XML 1.1 dependency testing for FOCH0001. Possibly the test typically succeeds most of the time because XML 1.0 is used with processors unless the dependency is set in the test. In such cases the FOCH0001 should always throw. 124759 2 benito 2016-01-30 09:57:49 +0000 >2) and one without the XML 1.1 dependency testing for FOCH0001. And with an XML 1.0 dependency 124764 3 abel.braaksma 2016-01-30 21:38:55 +0000 > And with an XML 1.0 dependency Such dependency does not exist, it is a minimum requirement to support XML 1.0. 124774 4 benito 2016-01-31 19:43:33 +0000 There is one: <dependency type="xml-version" value="1.0"/> 124776 5 abel.braaksma 2016-01-31 23:20:18 +0000 (In reply to Benito van der Zander from comment #4) > There is one: > > <dependency type="xml-version" value="1.0"/> Interesting. I just did a search and it is used 40x. Funny, never noticed it before. Looking at those tests I see how it is supposed to have meaning (i.e., should run on 1.0, not 1.1), though the more logical choice imho would be: <dependency type="xml-version" value="1.1" satisfies="false"/> Tx for pointing that out and sorry for the clutter... 125913 6 oneil 2016-04-19 12:04:26 +0000 I have split the tests according to comment #1. 125941 7 tim 2016-04-20 13:26:51 +0000 Would there be an objection to testing the result without using seialization-matches, as this test isn't really about serialization? For historical reasons, in our test harness we compare using canonical XML (as per the old XQTS), which happens not to escape this character. I fear if we change our test harness, we may end up having to file bug after bug about whitespace. 125942 8 mike 2016-04-20 13:44:53 +0000 Yes it's always good practice to avoid using serialization-matches assertions except when you're actually testing serialization. 126172 9 mike 2016-04-26 21:34:58 +0000 Changed the expected result to <assert>string-to-codepoints($result) eq 8</assert> 126250 10 tim 2016-04-28 08:11:24 +0000 Now updated. 126292 11 josh.spiegel 2016-04-28 18:44:30 +0000 I still see: <test-case name="K-CodepointToStringFunc-8a"> ... <assert-string-value>&#8;</assert-string-value> I am changing it to: <assert>string-to-codepoints($result) eq 8</assert> Currently I am unable to parse the catalog file with my 1.0 parser. 126295 12 tim 2016-04-29 08:21:08 +0000 (In reply to Josh Spiegel from comment #11) > Currently I am unable to parse the catalog file with my 1.0 parser. Sorry Josh - thanks for fixing it.