OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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



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.




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:


  1. 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.

  2. 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.

  3. 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.

  4. 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.






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]