Change draft for #158 (result.correlationGuid)

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

I pushed a change draft for Issue #158: Introduce result.correlationId and clarify purpose of result.fingerprints array

 

Documents/ChangeDrafts/Active/sarif-v2.0-issue-158-result-correlationGuid.docx

 

I will move its adoption at TC #19 on June 6^th.

 

The most important part of the change is this new section under “result object”, which I’m so pleased with that I reproduce it here:

3.19.3 Distinguishing logically identical from logically distinct results

Successive runs of the same tool, or even runs of different tools, might detect the same condition in the code. When two result objects represent the same condition, we say that the results are “logically identical;” when they represent different conditions, we say that the results are “logically distinct.” Two results can be logically identical even if the result objects are not identical. For example, if code was inserted into the file between runs, the same condition might be reported on two different lines.

 

To avoid reporting the same condition repeatedly, result management systems typically group results into equivalence classes such that results in any one class are logically identical and results in different classes are logically distinct. Some result management systems do this by calculating a “fingerprint” for each result and considering results with the same fingerprint to be logically identical. Other result management systems group results into equivalence classes without associating a computed fingerprint with each result, and they denote each equivalence class with an arbitrary unique identifier.

 

SARIF accommodates both types of result management systems. Result management systems that compute fingerprints SHOULD populate the fingerprints property (§3.19.12). Result management systems that group results into equivalence classes without computing a fingerprint SHOULD populate the correlationGuid property (§3.19.5).

 

Larry