This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20674 - [XT3TS] result-document-0202 and others
Summary: [XT3TS] result-document-0202 and others
Status: CLOSED WORKSFORME
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Abel Braaksma
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-15 15:40 UTC by Tim Mills
Modified: 2013-01-22 09:42 UTC (History)
1 user (show)

See Also:


Attachments

Description Tim Mills 2013-01-15 15:40:41 UTC
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
Comment 1 Michael Kay 2013-01-15 17:29:00 UTC
Couldn't we simply say that assert-serialization normalizes newlines before comparison?
Comment 2 Tim Mills 2013-01-15 22:05:11 UTC
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?
Comment 3 Michael Kay 2013-01-15 22:15:43 UTC
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.
Comment 4 Tim Mills 2013-01-16 14:04:50 UTC
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
Comment 5 Tim Mills 2013-01-16 14:05:57 UTC
Would you have any objection to me making them consistent?
Comment 6 Michael Kay 2013-01-16 14:19:09 UTC
No, go ahead and fix them.