- 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