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: RE: Change draft for #287: default for lastDetectionTimeUtc


I wrote a new change draft with the modified design:

 

Documents/ChangeDrafts/Active/sarif-v2.0-issue-287-lastDetectionTimeUtc-default-min-invocation-start-time.docx

 

… and moved the change draft with the original design to the Rejected folder:

 

Documents/ChangeDrafts/Rejected/sarif-v2.0-issue-287-lastDetectionTimeUtc-default-with-run-startTimeUtc.docx

 

Larry

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Monday, December 10, 2018 1:18 PM
To: Michael Fanning <Michael.Fanning@microsoft.com>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
Subject: [sarif] RE: Change draft for #287: default for lastDetectionTimeUtc

 

@michaelcfanning and I discussed this offline. I reminded him that the earliest invocation.startTimeUtc does not necessarily equal the run's start time (for reasons I explained in an earlier comment). He replied by reminding me of the driving scenario, which is:

... to identify the time of detection for a result. It is helpful for this value to be consistent, i.e., there should be a single timestamp for an analysis run. From this angle: find the earliest timestamp from the array of invocations seems fine as a simple, reliable way to get what’s required. I understand conceptually that doing this might not precisely describe the actual start of a run, but do we care?The real point here is: ‘this results has been raised since build XXX on date YYY’. We’re providing a slot for a date as a convenience, so that users aren’t required to go look up information associated with the instance id.

(Emphasis added)

I find that convincing, and I'm going to revise the change draft accordingly. We don't need to restore run.startTimeUtc (or run.endTimeUtc, which I had restored just for symmetry).

Larry

 

From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Monday, December 10, 2018 9:30 AM
To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
Subject: RE: Change draft for #287: default for lastDetectionTimeUtc

 

Hi, Larry,

 

I am not sure resurrecting run.startTimeUtc makes sense, please see my most recent reply.

 

I led us to this situation because I forgot that we removed this property. All things considered, introducing it again seems like it brings more complexity without much incremental value.

 

Michael

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Sunday, December 9, 2018 1:56 PM
To: OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
Subject: [sarif] Change draft for #287: default for lastDetectionTimeUtc

 

I pushed a change draft for Issue #287: “Define default for resultProvenance.lastDetectionTimeUtc”.

 

Documents/ChangeDrafts/Active/sarif-v2.0-issue-287-lastDetectionTimeUtc-default.docx

 

In the issue’s discussion thread, Michael and I decided that it made sense to bring back the property run.startTimeUtc. Please read the thread to see how that idea is related to this issue. So we’ve restored that property, and for symmetry, also restored run.endTimeUtc.

 

We’ll move its adoption at TC #29 on Wednesday December 12th.

 

Thanks,

Larry



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