RE: Two unrelated issues in one change draft

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) <>

Sent: Wednesday, February 13, 2019 2:52 PM

To: Larry Golding (Myriad Consulting Inc) <>; OASIS SARIF TC Discussion List <>

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:  <>
On Behalf Of Larry Golding (Myriad Consulting Inc)

Sent: Wednesday, February 13, 2019 2:03 PM

To: OASIS SARIF TC Discussion List <>

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:  <>
On Behalf Of Larry Golding (Myriad Consulting Inc)

Sent: Monday, February 11, 2019 5:32 PM

To: OASIS SARIF TC Discussion List <>

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