[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Does making resources.rules an array present a problem?
TL;DR: After consideration, I
don’t think there is actually a problem here. But please follow my argument to see if you agree. Consider a SARIF consumer that has in hand a
result object that specifies
ruleId. If the consumer needs any rule metadata
other than its id – for example, if it needs to display the message – then it needs
result.ruleIndex to locate the associated
rule object. If
resources.rules does not appear in the log file, the consumer must probe for an external localized resource file, which
might, for example, reside on a web site. This means that the external localized resource file
can never alter the order of the rule objects it contains. Newer versions of the file can’t reorder elements in the array or remove elements from the array. This wasn’t a problem when
resources.rules was a dictionary. Note that this is not a problem if the rules reside in a “external property file”, because such files are logically part of the root file. It’s only a problem if the consumer
has to probe for an external localized resource file. It is also not a problem for
run.files or
run.logicalLocations. On further consideration, I don’t think this is a real problem because external localized resource files are always associated with a particular version of the tool, so you’ll
have something like this: "tool": { "name": "CodeScanner", "version": "2.1.1", "language": "en-US", "resourceLocation": "https://www.contoso.com/CodeScanner/resources/2.1.1/", ... } So the SARIF consumer will always find the same version of the external localized resource file, and
ruleIndex will always be good. Do you agree? Thanks, Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]