RE: [sarif] Please review change draft for issues 33, 61, 69, and 72

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

I have made a change to the change draft: I added a rich text equivalent of the rule.help property. See Section 3.27.13, richHelp property.

 

Thanks,

Larry

 

From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org] On Behalf Of Larry Golding (Comcast)
Sent: Thursday, January 4, 2018 11:11 AM
To: sarif@lists.oasis-open.org
Subject: [sarif] Please review change draft for issues 33, 61, 69, and 72
Importance: High

 

Hello all,

 

A “change draft” of the SARIF spec is available which addresses several GitHub issues:

 

https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/sarif-v1.0-issues-33-61-69-72.docx

 

All changes are change-barred; you can use “Next change” to jump from one change to the next.

 

Please review the changes in this draft carefully. At the TC meeting on Wednesday January 10^th, I will separately move to adopt the changes related to each of these issues:

 

• Issue 33: Should we allow markdown in messages?
  
  Most SARIF objects which define a message property now also define an optional richMessage property. If richMessage is present, message must also be present to accommodate consumers that cannot render rich text. GitHub-Flavored Markdown (GFM) is the rich text language.
  
  The spec addresses the security issues raised by the use of rich text, especially Markdown.
• Issue 61: Provide a format for links embedded in our plain text messages
  
  We introduce the Markdown-like syntax [<link text>](<link target>), where <link target> is a non-negative integer, to allow the user to navigate from a message to a location mentioned in the result. That integer must match the value of the new physicalLocation.id property for some physicalLocation object in the result.
  
  Despite the issue title, this is allowed for both plain text messages and rich text messages.
• Issue 69: Provide a physicalLocation on a stack frame
  
  This is about replacing several existing properties on the stackFrame object with a single physicalLocation property which subsumes them.

 

This change draft also addresses an issue that I noticed and filed while I was making the above changes:

 

• Issue 72: run.lang property needs a default value.
  
  run.lang specifies the language of the messages within a run. We had not previously specified a default. We now specify that the default is "en-US".

 

This change draft also corrects a couple of inaccuracies in the text of the spec which I noticed while making the above changes. I added Word comments to point this out.

 

Finally, this change draft includes several editorial changes and clarifications, for example:

 

• In places where I previously referred to “name/value pairs” within a JSON object, I now call them by their correct JSON-ish name: “properties”.

 

Thanks,

Larry