Bug 19572 - fn-unparsed-text-038
fn-unparsed-text-038
Status: CLOSED FIXED
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite
Working drafts
PC Linux
: P2 normal
: ---
Assigned To: Tim Mills
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-17 08:59 UTC by O'Neil Delpratt
Modified: 2013-01-31 11:48 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description O'Neil Delpratt 2012-10-17 08:59:45 UTC
For the test fn-unparsed-text-038 we expect the error code FOUT1190. I think it should in addition expect the code FOUT1200.

In the test case the problem may occur when the processor cannot infer the correct encoding (i.e. FOUT1200) or if the file was incorrectly encoded (i.e. FOUT1190).

The spec states:

"An error is raised [err:FOUT1190] if the value of the $encoding argument is not a valid encoding name, if the ·processor· does not support the specified encoding, if the string representation of the retrieved resource contains octets that cannot be decoded into Unicode ·characters· using the specified encoding, or if the resulting characters are not permitted XML characters.

An error is raised [err:FOUT1200] if $encoding is absent and the ·processor· cannot infer the encoding using external information and the encoding is not UTF-8."

If the creator of the test agrees I can make the change.
Comment 1 Tim Mills 2012-10-19 16:32:33 UTC
I partially agree - I'm assuming your processor isn't using the information in resource/@encoding, which could lead to FOUT1200.

However, I'd rather target the test to hit FOUT1190 alone.

I have added a new file which contains a utf-8 byte order mark at the beginning, but is invalid UTF-8.

Would you agree that this should only trigger FOUT1190?
Comment 2 Tim Mills 2013-01-30 22:19:16 UTC
Do you have any further comments or would you be happy to close?
Comment 3 O'Neil Delpratt 2013-01-31 10:27:15 UTC
I agree with comment #1 and have no further comments
Comment 4 Tim Mills 2013-01-31 11:48:09 UTC
Great.  Closing...