sarif — archive

RE: recommendedArtifactDisplayBase

From: Michael Fanning
To: [email protected]
Date: Thu, 25 Apr 2019 19:31:00 -0000

Note that in Jim’s example, the SARIF_DISPLAYBASE definition is additive. That is, there is a distinct definition for this uriBaseId which is inserted as an additional hint/information. If you removed this hint, the remaining information is coherent (ie, all URIs can still be properly constructed/understood from the remaining data). We should consider whether this is a useful constraint to put into the spec. The value of doing so is that we remove SARIF_DISPLAYBASE from being consumed in a general way by viewers (in scenarios where, for example, the viewer finds its useful to reflect uriBaseIds in order to accurately reflect repository nesting). Instead, SARIF_DISPLAYBASE is just a special kind of named uriBaseId value that has a specific purpose to facilitate viewer development. If we agree that separating SARIF_DISPLAYBASE in this way is helpful, of course, we have to ask why we don’t create a dedicated property for it, as Jim originally suggested. From: Larry Golding (Myriad Consulting Inc) <[email protected]> Sent: Thursday, April 25, 2019 10:53 AM To: James Kupsch <[email protected]>; Michael Fanning <[email protected]>; [email protected] Subject: RE: recommendedArtifactDisplayBase I opened Issue #396 for this. Michael and I agree with Jim’s suggestion to specify a distinguished value in originalUriBaseIds to server as a path display hint to viewers. I also agree with Jim’s “future-proofing” suggestion to make it SARIF_DISPLAYBASE and reserve all originalUriBaseIds property names starting with SARIF_. Larry