RE: recommendedArtifactDisplayBase

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) <>
Sent:  Thursday, April 25, 2019 10:53 AM
To:  James Kupsch <>; Michael Fanning <>; 
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