I uploaded a sample SARIF file to illustrate the changes:
https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ScratchSamples/179-311.sarif Please take a look at your earliest convenience. I’m going to start writing now because Michael and I have looked at this quite carefully, including implementing it in the SDK, so we’re pretty confident in the structure. Thanks, Larry From: Larry Golding (Myriad Consulting Inc) <
v-lgold@microsoft.com> Sent: Wednesday, February 13, 2019 2:52 PM To: Larry Golding (Myriad Consulting Inc) <
v-lgold@microsoft.com>; OASIS SARIF TC Discussion List <
sarif@lists.oasis-open.org> Subject: RE: Two unrelated issues in one change draft I missed a few properties below. We also need: In the notification object: · Rename the property ruleId to associatedRuleId . // The two renames are to clarify that this id and index do not refer to the notification itself, but rather to the rule (if any) to which the notification is relevant. Example: “The rule CS2001 threw an exception and has been disabled.” · Rename the property ruleIndex to associatedRuleIndex . · Add a property associatedRuleExtensionIndex of type integer , default: -1 . optional. · Add a property notificationIndex of type integer , default: -1 . optional. · Add a property notificationExtensionIndex of type integer , default: -1 . optional. Thanks, Larry From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Wednesday, February 13, 2019 2:03 PM To: OASIS SARIF TC Discussion List <
sarif@lists.oasis-open.org > Subject: [sarif] RE: Two unrelated issues in one change draft Here is the net result of these two changes, as summarized in the schema changes document . ( The comments do not appear in the schema changes document.) I am crafting a sample SARIF file to demonstrate all this, but I wanted to get this out to you ASAP. Please take a look , because this is going to be a lot of writing! Issue #179 : "Consider whether SARIF covers plug-ins/rules versioning sufficiently" and Issue #311 : "Provide full metadata objects for notifications" NOTE: We describe the combined result of both of these changes, because both of them affect the location of rule metadata. Rename the existing rule object to reportingDescriptor . // because it applies to notifications as well as results, now. Rename the existing ruleConfiguration object to reportingConfiguration Define a toolComponent object with the following properties: · All previously existing properties of the tool object except for language . · globalMessageStrings of type object with property values of type string , moved and renamed from resources.messageStrings , optional. · ruleDescriptors of type reportingDescriptor[] , moved and renamed from resources.rules , optional. · notificationsDescriptors of type reportingDescriptor[] , optional. · fileIndex of type integer , default: -1 , optional. // so we can have information about the component like its file hashes and its location. In the tool object: · Remove the sarifLoggerVersion property. // Unrelated change. Michael invented it but never used it. · Move all remaining properties except for language into the new toolComponent object. · Add a property driver of type toolComponent , required. · Add a property extensions of type toolComponent[] , minItems: 0 , unique, optional. In the reportingDescriptor object (renamed from rule ): · Rename the configuration property to defaultConfiguration . In the reportingConfiguration object (renamed from ruleConfiguration ): · Rename the defaultLevel property to level . · Rename the defaultRank property to rank . Define a reportingConfigurationOverride object with the following properties: · ruleIndex of type integer , optional, default: -1 . · notificationIndex of type integer , optional, default: -1 . // Exactly one of ruleIndex and notificationIndex must be present. This tells us whether we are configuring a rule or a notification. · extensionIndex of type integer , optional, default: -1 . · configuration of type reportingConfiguration , required. In the invocation object: · Add a reportingConfigurationOverrides property of type reportingConfigurationOverride[] , optional. In the run object: · Remove the resources property. Remove the resources object. In the result object: · Add a property extensionIndex of type integer , default: -1 , optional. // goes along with ruleIndex so we can locate metadata for rules defined in an extension In the conversion object: · Rename the tool property to driver , and change its type from tool to toolComponent . // name change for parallelism with tool . Leaves open possibility that converters could have extensions in future. Thanks, Larry From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Monday, February 11, 2019 5:32 PM To: OASIS SARIF TC Discussion List <
sarif@lists.oasis-open.org > Subject: [sarif] Two unrelated issues in one change draft For practical reasons, I’m going to produce a change draft that contains two seemingly unrelated changes: Issue #179 : Consider whether SARIF covers plugins/rule versioning sufficiently. Issue #311 : Provide full metadata objects for notifications. The reason is that both of these changes have an effect on where the rule metadata ends up: Issue #311 moves the rule metadata into the tool object, but then… Issue #179 breaks the tool object into a set of toolComponent objects… … and the end result is that rule metadata ends up living in toolComponent . Since we agreed in principle to both of these changes during the F2F, I’m not worried about wasting effort by combining the drafts, and I think it will help you to see the overall result in a single draft. I should be able to get a draft out by end of day tomorrow. Thanks, Larry