Question "claims to test an illegal char, but tests the wrong char" about parse-xml HOT 3 CLOSED

Nice job! I'm happy to have run across this.

Thanks!

I see some of your conformance test exceptions (e.g. not-wf-sa-173) say "claims to test an illegal char, but tests the wrong char". How are these the wrong character?

Good catch. It looks like not-wf-sa-173 may have been skipped by mistake, since it does in fact appear to test the correct char.

not-wf-sa-168 is an example of a test case whose description claims that it tests the presence of an unpaired surrogate, D800, but D800 doesn't actually appear in the test case. I'm not sure exactly why this is, but I suspect some of the test cases (which I downloaded directly from https://www.w3.org/XML/Test/xmlconf-20020606.htm) may have encoding issues. Either that or I'm missing something?

from parse-xml.

Good catch.

Actually, just a random catch. I just happened to poke there.

not-wf-sa-168

This is a weird one. The file is utf8 and has 0xed 0xa0 0x80 in it which is actually 0xD800 in utf8 ( https://www.compart.com/en/unicode/U+D800 ) So, I think that's the right thing?

from parse-xml.

Ah, I think I see what's happening. When the test case is read by fs.readFile(), 0xED, 0xA0, and 0x80 each become U+FFFD because Node's Buffer#toString() refuses to produce an invalid UTF-8 string. Since U+FFFD is valid in an XML document, parsing succeeds when the test expects it to fail.

When I manually construct an XML doc in the Node.js REPL containing U+D800 and try to parse it, parseXml fails as it should:

> parseXml('<doc>\uD800</doc>')
Uncaught Error: Invalid character (line 1, column 6)
  <doc>�</doc>

I'm not sure if there's a good way to read this test file and feed it to parseXml while preserving the invalid byte sequence, but I suppose I could convert it to a manual test. Will give this some thought.

from parse-xml.