We have discussed preferring/permitting markdown for representing SARIF messages. In part, we have considered this in order to support embedding links in output. As an alternate, we could simply permit embedded links in plain text messages (which could themselves follow the markdown format). This has the downside of introducing a 'mini-language' into the format. That mini-language can follow an existing standard, however (markdown). By restricting markdown use to this narrow scenario, we can also describe a way for SARIF message consumers that can't support an actual inlined link to display the content in a reasonable way. Issue #33 refers to the broad problem of formatting in messages. This issue also relates to #57, as an embedded link typically references a region in the file that is linked to.

Markdown support for links is relatively rich. For simplicity we should likely pick the smallest useful subset. One proposal would be to support the standard link text + link + link title syntax:

link text here

An example SARIF message:

A call to 'Start' may result in arbitrary code execution. The untrusted data that flows into this call site originated [here](http://somefile.cpp#startLine=10 SomeFile.cpp)

A link consumer would convert this into a clickable link. A pure plain-text viewer would parse this, trim the hover link text and render as so:

A call to 'Start' may result in arbitrary code execution. The untrusted data that flows into this call site originated here (http://somefile.cpp#startLine=10)

Additional complexities: if we define a protocol for referencing files that are stored in the object, consumers will need to potentially go locate the actual URI for the file (SARIF allows for files to be referenced by arbitrary key, to accommodate situations where there may be file name collisions)