[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]