OASIS Static Analysis Results Interchange Format (SARIF) TC

  • 1.  RE: New TC comment: Issue #429, missing constraint

    Posted 07-08-2019 03:09
    Hmmm. I see that I had previously decided not to take this change. In the heat of editing this afternoon, I did make this change – it seemed at the time an obvious bug that needed fixing.   David, please let me know whether to revert this change in the draft I just pushed.   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Friday, June 14, 2019 5:38 PM To: OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org> Subject: [sarif] New TC comment: Issue #429, missing constraint Importance: High   I noticed and filed Issue #429 , “Missing constraint: result.ruleId == result.rule.id”:   The spec correctly says that if  result.ruleIndex  and  result.rule.index  are both present, they must be equal. But it does  not  say that if  result.ruleId  and  result.rule.id  are both present, they must be equal. It  should  say that.   I was sure I’d said that, but I just can’t find it in §3.27.5, result.ruleId property.   It would be a substantive change to add this constraint. I propose not to take this change (and trigger another comment period). It’s not like somebody’s likely to create a SARIF file that looks like this:   results: [   {     ruleId: CS0001,     rule: {      id: CS0002     },     ...   It’s just that we should have explicitly prohibited it.   Larry


  • 2.  Re: [sarif] RE: New TC comment: Issue #429, missing constraint

    Posted 07-08-2019 03:22
    Larry, As long as only editorial changes are made, the current draft should reflect your best current thinking, even if you have changed your mind along the way. It is fine to revert the change if that is what you currently believe is best. You can explain your reasoning at Wednesday's meeting (or before) and the committee can discuss it before deciding whether to ask for a Special Majority Vote for Committee Specification. David On 2019-07-07 20:08, Larry Golding (Myriad Consulting Inc) wrote: Hmmm. I see that I had previously decided /not/ to take this change. In the heat of editing this afternoon, I did make this change it seemed at the time an obvious bug that needed fixing. *David,* please let me know whether to revert this change in the draft I just pushed. Larry *From:* sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> *On Behalf Of *Larry Golding (Myriad Consulting Inc) *Sent:* Friday, June 14, 2019 5:38 PM *To:* OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org> *Subject:* [sarif] New TC comment: Issue #429, missing constraint *Importance:* High I noticed and filed Issue #429 < https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fsarif-spec%2Fissues%2F429&data=02%7C01%7Cv-lgold%40microsoft.com%7C52449c5b679449d2bd8508d6f129aeb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636961558658965200&sdata=J9f8YnTE8knQhKiKY0Zh3NFf4YXk%2Fiu3jGT6cVAjMJU%3D&reserved=0 >, Missing constraint: result.ruleId == result.rule.id : The spec correctly says that if result.ruleIndex and result.rule.index are both present, they must be equal. But it does /not/ say that if result.ruleId and result.rule.id are both present, they must be equal. It /should/ say that. I was sure I d said that, but I just can t find it in 3.27.5, result.ruleId property. It would be a substantive change to add this constraint. I propose /not/ to take this change (and trigger another comment period). It s not like somebody s likely to create a SARIF file that looks like this: results: [ { ruleId: CS0001, rule: { id: CS0002 }, ... It s just that we should have explicitly prohibited it. Larry


  • 3.  RE: [sarif] RE: New TC comment: Issue #429, missing constraint

    Posted 07-08-2019 03:27
    Thanks David. The question is whether we consider this change editorial or substantive. In my current thinking, neglecting to explicitly specify that result.ruleId must be the same as result.rule.id was a simple oversight, of the same order as leaving a word out of a sentence -- how could result.ruleId and result.rule.id possibly be different? I will keep it in for now. If the TC disagrees on Wednesday, I will remove it on the spot and we can then vote on the resulting, modified version. Larry
    Original Message


  • 4.  Re: [sarif] RE: New TC comment: Issue #429, missing constraint

    Posted 07-08-2019 03:53
    Larry, If the committee unanimously agrees that no reasonable implementation could be impacted by this change, we can accept it as non-material. If anyone objects, no big deal; we can just revert the change. David On 2019-07-07 20:27, Larry Golding (Myriad Consulting Inc) wrote: Thanks David. The question is whether we consider this change editorial or substantive. In my current thinking, neglecting to explicitly specify that result.ruleId must be the same as result.rule.id was a simple oversight, of the same order as leaving a word out of a sentence -- how could result.ruleId and result.rule.id possibly be different? I will keep it in for now. If the TC disagrees on Wednesday, I will remove it on the spot and we can then vote on the resulting, modified version. Larry
    Original Message


Related Content