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: [sarif] Quasi-editorial change: the "baseline run"


Sorry, I meant "will need out of band information *if* baselineInstanceGuid is absent."

					David

On 2018-05-17 15:42, David Keaton wrote:
     I am uneasy about this change because it tries to specify things that are outside the scope of the standard.  I think it would be better to have a non-normative note that a SARIF consumer will need out of band information baselineInstanceGuid is absent.

                     David

On 2018-05-17 11:42, Larry Golding (Comcast) wrote:
/Please read to the end for a not-quite-editorial change that you might want to comment on./

At TC #18, while reviewing the new values for file.roles, we discussed how to specify the run to which the files marked with these roles should be compared. It turns out that we had already encountered this issue with result.baselineState, where we wrote:

If the baselineId property (§3.11.4) of the containing run object (§3.11) is present, the baseline *SHALL* be the run specified by that baselineId.

If the baselineId property of the containing run object is absent, then a SARIF consumer will need out of band information available to determine the baseline.

But we can do better, now that we have the “Engineering system” conformance profile. So, following our usual practice of abstracting a concept we’ve encountered twice, we introduce the following definition in the Terminology section:

baseline run

run <#def_run> that produces a baseline <#def_baseline> to which subsequent runs can be compared

With that definition in hand, we can improve our description of result.baselineState:


      *3.19.18 [result.]baselineState property***

A result object *MAY* contain a property named baselineState whose value is a string that specifies the state of this result with respect to some previous run, which we refer to as the “baseline run.”

If baselineInstanceGuid (§3.11.4) is present on the containing run object (§3.11), its value *SHALL* specify the baseline run. If baselineInstanceGuid is absent, the engineering system *SHALL* provide out of band information that determines the baseline run.

… and we can then use similar language for the new values of file.roles:


        *3.17.6 [file.]roles property***

…

The following role values denote files that have changed since the “baseline run”. If baselineInstanceGuid (§3.11.4) is present on the containing run object (§3.11), its value *SHALL* specify the baseline run. If any of these role values are present but baselineInstanceGuid is absent, the engineering system *SHALL* provide out of band information that determines the baseline run.

*NOTE:* The statement that the new roles can be computed with respect to a run /other than/ baselineInstanceGuid is not an editorial change. That is a substantive change that we agreed on in TC #18. The editorial change is to introduce that term “baseline run” and to use similar (and improved) language.

*NOTE*: Technically speaking, the new normative statement that “the engineering system *SHALL* provide out of band information…” – as opposed to the previous non-normative statement that “a SARIF consumer will need out of band information…” – is a substantive change, but I hope you’ll either (a) agree that it falls within editorial discretion, or (b) agree with the change! If not, let me know.

Larry



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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