RE: Default value for resultProvenance.lastDetectionTimeUtc is tricky: deferred

I chose to do the bookkeeping for this by closing 
Issue #272 (“Introduce resultProvenance object”) as 
resolved-fixed and opening new 
Issue #287 (“Define default for resultProvenance.lastDetectionTimeUtc”) to capture the remaining question. I put it on the agenda for TC #28.

 

From:  <>
On Behalf Of Larry Golding (Myriad Consulting Inc)

Sent: Friday, November 16, 2018 3:28 PM

To: OASIS SARIF TC Discussion List <>

Subject: [sarif] RE: Default value for resultProvenance.lastDetectionTimeUtc is tricky: deferred

 

We actually had this problem of “what is the run’s start time” even before we amended the draft to introduce
lastDetectionTimeUtc and its default value. Notice what the change draft said about
firstDetectionTime:

 

It SHOULD specify 
the start time of the run in which the result was first detected, as opposed to, for example, the time within the run at which the result was actually generated.

NOTE: Using the run’s start time makes it possible to group together results that were first detected in the same run.

So somehow we need to say what we mean by “run start time”, for instance, with Option 1 or Option 2 below.

 

From:  <>
On Behalf Of Larry Golding (Myriad Consulting Inc)

Sent: Friday, November 16, 2018 3:13 PM

To: OASIS SARIF TC Discussion List <>

Subject: [sarif] Default value for resultProvenance.lastDetectionTimeUtc is tricky: deferred

 

TL;DR:

 

The default value logic for resultProvenance.lastDetectionTimeUtc is trickier than we imagined when we discussed it in TC #27. For now, I will not specify a default in the provisional
 draft. I added an agenda item to revisit it in TC #28.

 

Details:

 

In TC #27, we agreed to amend the change draft for 
Issue #272 (“Introduce resultProvenance object”) by adding 
lastDetectionTimeUtc, and defaulting it to the start time of the current run. When I started writing, a couple of complications emerged:

 

If the
level property (§3.21.7) of the containing
result object (§3.21) has any value except
"pass" or
"notApplicable", and if the
startTimeUtc property (§???) of the containing
run object (§3.12) is present, then
lastDetectionTimeUtc shall default to the value of that
startTimeUtc property.

 

First of all, we shouldn’t consider a result in the current run to constitute a “detection” unless the problem really
was detected in this run. We didn’t consider that during TC #27.

 

Second – the
run object doesn’t have a 
startTimeUtc property! That property is on the 
invocation object, and a run can have an array of invocations. The SARIF consumer won’t know which invocation’s start time to use for the default.

 

There are a few possibilities:

 

Jim has actually suggested (offline) that we add a mechanism to relate a result to an invocation, although I hadn’t yet filed an issue for it. I’ve now filed

Issue #285, “Provide a mechanism to associate a result with an invocation”.

When I first saw that suggestion, I imagined defining 
result.invocationIndex. But now that we have 
resultProvenance, IMO that’s the most natural place for it. So we could add
resultProvenance.invocationIndex, and use the
startTimeUtc of the specified invocation object as the default for
lastDetectionTimeUtc.

We could specify that the default for lastDetectionTimeUtc is
the minimum of the startTimeUtc values over all the
invocation objects in 
run.invocations. That would effectively be the run’s start time.

We could decide that the default logic for lastDetectionTimeUtc is too complicated, and
not specify a default. If you want it, you have to populate it.

Other ideas?

 

Note that even if we chose Option 2 or Option 3, 
resultProvenance.invocationIndex would still be useful. We just wouldn’t use it to calculate the default for
lastDetectionTimeUtc.

 

Thanks,

Larry