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 following tests have serializations which use '\n' as the newline character. Elsewhere in the test suite, the newline characters used is '\r\n'. output-0201 output-0202 output-0203 output-0205 output-0206 result-document-0202
Couldn't we simply say that assert-serialization normalizes newlines before comparison?
We do byte-by-byte comparison of the serialised result against the expected result. To get around the problem, we serialise the result both with \n and \r\n and try the comparison with each. Is it safe to replace a 13 10 byte sequence with 10 without reference to the text encoding, or would we have to use the output encoding to decode the byte stream, do the character replacement, then re-encode to a byte stream?
I don't think we yet have mechanisms to make assertions against the binary encoding of the serialized output (though I remember thinking about how to do it). I think that the assert-serialization assertion is comparing characters, not bytes, and relies on you either (a) capturing the characters before they are encoded, or (b) decoding the binary serialization back to characters. So you should be able to normalize line endings at the character level.
What I'm currently doing works well enough, but most tests appear to have been encoded with \r\n, so I presumed it was intended to be consistent. If I remember correctly, CVS sorts this out automagically. Presumably mercurial doesn't. I only recently switched to comparing the bytes, and can't quite remember why I made the change - I'll check my SVN logs to find out why. BTW, there are broken links and requests for authentication for some links in the documentation at: http://dev.w3.org/2011/QT3-test-suite/guide/running.html 3.g. http://dev.w3.org/2011/QT3-test-suite/guide/catalog-schema.html
Would you have any objection to me making them consistent?
No, go ahead and fix them.