Agreed, and I trust Jim’s judgment most here because he has most experience with complex conversion scenarios. This situation has never materialized in any Microsoft driven converter scenarios. Most of SARIF (I hope) is proposed for well-substantiated
use cases, in general, ‘allowing for possibilities’ isn’t a typical design principle.
Michael
From: Larry Golding (Comcast) <>
Sent: Tuesday, March 27, 2018 2:19 PM
To: Michael Fanning <>;
Subject: RE: [sarif] Issue #134: conversion.analysisToolLogFileLocation should be an array
Jim can help answer “does any tool behave that way today”. The question “is it a good idea to allow for the possibility” is more a judgment call.
Larry
From: Michael Fanning <>
Sent: Tuesday, March 27, 2018 2:15 PM
To: Larry Golding (Comcast) <>;
Subject: RE: [sarif] Issue #134: conversion.analysisToolLogFileLocation should be an array
This is Jim’s to answer, is my guess.
Michael
From: <>
On Behalf Of Larry Golding (Comcast)
Sent: Tuesday, March 27, 2018 10:28 AM
To:
Subject: RE: [sarif] Issue #134: conversion.analysisToolLogFileLocation should be an array
Importance: High
I looked more closely at this, and I want to make sure that this is the right change. As the spec stands, it covers the following scenarios:
The analysis tool produces a
exactly one log file containing all results. This is the most common scenario. In this case, the converter populates
conversion.analysisToolLogFileLocation with the location of that file.
The analysis tool produces
one or more separate log files for each result. In this case, for each result, the converter populates
result.conversionProvenance[n].analysisToolLogFileLocation with the locations of those result-specific files. Note that
result.conversionProvenance is an array of
fileLocation objects {*}.
The spec does not convered this scenario:
The analysis tool produces
more than one log file, each of which contains a portion of the information for
all results. This is the case were we would want
conversion.analysisToolLogFileLocations to be an array.
So – Is #3 a realistic scenario? Even if no tool behaves that way today, wouldn’t it be a good idea to allow for the possibility?
Thanks,
Larry
{*} Fun fact: this is the only place in the spec where an array-valued property does not have a plural name. We discussed “conversionProvenances” and rejected it.
From: <>
On Behalf Of Larry Golding (Comcast)
Sent: Tuesday, March 27, 2018 9:19 AM
To:
Subject: [sarif] Issue #134: conversion.analysisToolLogFileLocation should be an array
Importance: High
I just noticed this. It’s a tiny change and I think we need it for CSD.1:
Some analysis tools emit multiple files. A converter might need more than one of them to produce a SARIF log file.
So the property conversion.analysisToolLogFileLocation of type fileLocation should
be changed to analysisToolLogFileLocations of type fileLocation[].
Larry
