- From: <bugzilla@jessica.w3.org>
- Date: Wed, 21 Oct 2015 11:26:40 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29217 Bug ID: 29217 Summary: Serialization of newlines Product: XPath / XQuery / XSLT Version: Candidate Recommendation Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: Serialization 3.1 Assignee: cmsmcq@blackmesatech.com Reporter: christian.gruen@gmail.com QA Contact: public-qt-comments@w3.org Target Milestone: --- When serializing results, I frequently stumble across the OS-specific handling of newlines. For the text output method, the serialization spec states that "A newline character in the instance of the data model MAY be output using any character sequence that is conventionally used to represent a line ending in the chosen system environment.". Based on this info, I would be interested what are the valid serializations of the following strings: a) 
 b) 
 c) 
 d) 

 ...assuming that an OS uses \r\n, \n or \r for representing a newline. This is what I would currently assume (but I guess I’m wrong?): -------------------------------------------------- Input | Linux | Windows | Mac (old) -----------------|---------|-----------|---------- 
 | \r | \r | \r 
 | \n | \r\n | \r 
 | \r\n | \r\r\n | \r\r 

 | \r\r\n | \r\r\r\n | \r\r\r -------------------------------------------------- Maybe this could be clarified in the spec? The following QT3TS test case seems to be related: It assumes \n to be always serialized, whereas \r is only expected if it does not occur before \n: <test-case name="Serialization-text-11" > <description> Ensure a new-line character is NOT escaped. </description> <created by="Michael Kay" on="2015-04-09"/> <test><![CDATA[ declare option Q{http://www.w3.org/2010/xslt-xquery-serialization}method "text"; "a
aa
a
"]]></test> <result> <serialization-matches><![CDATA[^a\raa\r?\na\r?\n$]]></serialization-matches> </result> </test-case> Thanks in advance. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 21 October 2015 11:26:43 UTC