3635 2006-08-26 21:28:46 +0000 prolog-version-2 2006-09-01 07:32:00 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite 1.0 PC Windows XP RESOLVED FIXED P2 normal --- 1 mike carmelo public-qt-comments oldest_to_newest 11293 0 mike 2006-08-26 21:28:46 +0000 The query file prolog-version-2.xq has an encoding declaration asserting that it is encoded in UTF-16 - but it isn't. The handling of an incorrect encoding declaration is entirely implementation-dependent. In this case it appears that Saxon on the Java platform recovers from the error, but on the .NET platform it falls over with a random syntax error. 11306 1 andrew.eisenberg 2006-08-29 19:13:39 +0000 I agree that the query should be UTF-16 encoded to match the declaration in the prolog. In section 4.1, Version Declaration, XQuery says, "The handling of an encoding declaration is implementation-dependent." We don't specify an error in this clause, other than XQST0031, which is concerned only with the name of the encoding. I think that this test case should accept a parse error, XPST0003, from implementations that don't support UTF-16 queries. 11308 2 mike 2006-08-29 19:24:17 +0000 There's a reason that we don't specify an error code, namely that we recognize that the error might be detected not by the query processor, but by some low-level software perhaps in the operating system, which might be difficult for the query processor to trap and interpret. It might even result in the query processor parsing and executing a different query from the one intended! So I don't think this case belongs in the test suite, since the outcome is so unpredictable. 11341 3 carmelo 2006-08-31 17:30:32 +0000 I sort of agree with Michael on this one. Perhaps the test does needs to be removed. Any thoughts? Carmelo 11342 4 frans.englich 2006-08-31 17:38:57 +0000 Accepting XPST0003 would only make the test pass for implementations that issue XPST0003(since it's implementation defined, no one is required to issue XPST0003). I think it is important to have tests that are in the UTF-16 encoding, so I believe the correct resolution is to keep the test and keep 'xquery version "1.0" encoding "utf-16";', but to convert the file to actually be in UTF-16 encoding. Frans 11343 5 carmelo 2006-08-31 17:45:59 +0000 Frans: Thanks. I can be persuaded either way. Do you know of any UTF-16 conversion tools? carmelo 11344 6 carmelo 2006-08-31 18:35:39 +0000 Frans: Never mind, I found a way to reformat the file. Submitted new file on UTF-16 format. Thanks. carmelo 11346 7 davidc 2006-08-31 20:54:49 +0000 I think the catalog ought to flag the encoding of the file (anywhere, eg encoding="utf-16" in the query element). A system might be able to read in utf16 (and check the encoding specified) if it is given warning of the encoding. It needn't be ableto be auto detect the encoding from the prplog (eg the guidelines give examples saying teh query may be embedded in a host language, eg sql in which case the encoding of the file would necessarily be determined by the host language parser. 11349 8 Tom.Brosens 2006-09-01 07:32:00 +0000 That's +1 for David's solution. Although we could auto-detect the encoding it would be a lot easier if the encoding is in the catalog for query files which are not UTF-8 encoded. Thanks, Tom.