We should produce documentation that describes the sample files and how they should be used by consumers. This will allow viewer developers to try to exercise the test assets in a productive way without understanding all the many nuances expressed in the SARIF spec (which is only obvious to people with a deep understanding of the spec). For example:
The "suppressions" sample should explicitly call out that this data is designed to ensure that viewers correctly exclude or include suppressed results (and don't surprise users by showing those results in a way that suggests they are active and should be addressed).
The originalUriBaseIds sample should be helpful for viewers that are attempting to remap relative links in a SARIF log file. If a log is viewed in an environment that maps directly to the paths expressed in an original uri base id (i.e., the local enlistment matches the analysis, or the local machine was itself used for the scan), consumers should be able to successfully stitch together working links, using other information expressed in the physical location data.
Per @michaelcfanning:
We should produce documentation that describes the sample files and how they should be used by consumers. This will allow viewer developers to try to exercise the test assets in a productive way without understanding all the many nuances expressed in the SARIF spec (which is only obvious to people with a deep understanding of the spec). For example:
originalUriBaseIdssample should be helpful for viewers that are attempting to remap relative links in a SARIF log file. If a log is viewed in an environment that maps directly to the paths expressed in an original uri base id (i.e., the local enlistment matches the analysis, or the local machine was itself used for the scan), consumers should be able to successfully stitch together working links, using other information expressed in the physical location data.