Some tool-specific messages may warrant their own descriptive objects as we have for rules. The reason is that various notifications are commonly occurring adverse conditions that need to be documented and understood as part of a standard support scenario.

A canonical example: 'Rule {0} raised an unhandled exception and was disabled during analysis (which may be incomplete. To temporarily disable this check, pass --disable:{1} on the command-line.'

This string documents an adverse condition that may show up in log files. It therefore may warrant its own help topic, descriptive text, etc. It is helpful for this descriptive information to be documented in an exhaustive SARIF log file that contains a snapshot of all possible user-facing strings.

[Note that this message also demonstrates why a notification may provide both a ruleId and a ruleIndex (pointing into a rule descriptive object). In this case, the rule id is used as arg {1} to form an argument to disable a check by its id. The underlying notification.ruleIndex is used to look-up the rule's friendly rule.name value to pass as a readable identifier in arg {0}].

Simplest idea might be to generalize resources.rules to a more general name that covers descriptors for both notifications and rules. run.resources.messageDescriptors. result.ruleIndex would then represent a rule descriptor index (which could be the name, though long).

A second strategy might be to define a run.resources.notifications property. the elements of this array (and resources.rules) could be the same underlying thing. The arrays would allow for separation of purpose (otherwise we might need an enum on each descriptor to document whether it is a notification or rule descriptor).

Another thinking scenario to serve as an exampl: pdb loading. Many rules may depend on PDBs in order to get access to sufficient data to perform analysis. It is clear that a single help topic would make sense for resolving this adverse condition. According to SARIF, this message s/be a notification (an error that indicates the analysis is not properly configured to run, because the PDBs are missing or because the symbol server was not properly configured on the command-line). Another case for a notification descriptor: a common format string is not sufficient.
@lgolding