Change draft for #103 (line breaks)

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

I pushed a change draft for Issue #103, “Specify handling of line breaks”:

 

Documents/ChangeDrafts/Active/sarif-v2.0-issue-103-follow-source-file.docx

 

I will move its adoption at TC #17 on May 16^th.

 

The changes are simple, and confined to two sections:

 

3.2.2   [fileContent.]text property

If the external file is a text file, a fileContent object SHOULD contain a property named text whose value is a string containing the relevant text. Since SARIF log files are encoded in UTF-8 ([RFC3629]; see §3.1), this means that if the external file is a text file in any encoding other than UTF-8, the SARIF producer SHALL transcode the text to UTF-8 before assigning it to the text property. The SARIF producer SHALL escape any characters that [RFC8259] requires to be escaped.

Notwithstanding any necessary transcoding and escaping, the SARIF producer SHALL preserve the text file’s line breaking convention (for example, "\n" or "\r\n").

If the external file is a binary file, the text property SHALL be absent.

 

3.9.2   Plain text messages

A plain text message SHOULD be expressed as a single paragraph of plain text, consisting of one or more complete sentences, each ending with a period (or appropriate punctuation for the language in which the message is written). The message SHALL NOT contain formatting information such as HTML tags.

The message SHOULD NOT contain JSON escaped line breaks (\r or \n). However, if line breaks are present, they MAY follow any convention (for example, "\n" or "\r\n"). A SARIF post-processor MAY normalize line breaks to any desired convention, including escaping or removing the line breaks so that the entire message renders on a single line.

The message string MAY contain placeholders (§3.9.4) and embedded links (§3.9.5).

 

Larry