OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Please review change draft for issues 33, 61, 69, and 72

Hello all,


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




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 10th, 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”.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]