This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.
I sort of agree with Michael on this one. Perhaps the test does needs to be removed. Any thoughts? Carmelo
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
Frans: Thanks. I can be persuaded either way. Do you know of any UTF-16 conversion tools? carmelo
Frans: Never mind, I found a way to reformat the file. Submitted new file on UTF-16 format. Thanks. carmelo
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.
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.