[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Does making resources.rules an array present a problem?
|
Yes. This is a situation where it’s hard to resolve distinct issues without considering all of them. Really, we should be thinking about the plug-ins problem as well to be
sure all decisions are stable. Let’s have an ad hoc telecon. I’ll send an invite to this list. We can recap discussion afterwards here for anyone who can’t attend. Michael From: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
There are two distinct issues here:
The reason we have conflated these issues is that if resources.rules is an array, then the tool vendor has to exercise more discipline in updating and versioning his online
resource files. But question #2 exists whether resources.rules is a dictionary or an array. Larry From: Michael Fanning <Michael.Fanning@microsoft.com>
Right. See my other mail. I think the question hinges on the use for synthetic keys for rules. The spec does not recall the specifics of the need for this (perhaps you can
point me to good content). I’ll go take a look at the large body of SDK samples to see if I can get a clue. The thing I keep thinking about is that a tool itself controls this data domain (i.e., its rule identifiers). A run consists of information exclusively generated by a single
tool of a single version (modulo the plug-ins problem, might as well throw that topic on the thinking pile). Michael From: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
Finally (sorry these thoughts didn’t occur to me all at once), although you could say that an array and an object are “inconsistent”, we made an explicit choice to use arrays
for anything that was either (1) large, like run.results, or 2) might have synthetic keys, like
run.files, and to use dictionaries for anything else.
resources.rules satisfies those criteria (it might have synthetic keys, for the reason I recalled to you below), while
resources.messageStrings does not. I do agree that specifying a detailed probing order might be getting beyond our expertise. We could limit ourselves to saying that all the localized resource files have to
live somewhere under the directory specified by tool.resourceLocation, and leave it at that. But that would leave it up to each
tool vendor to specify a layout, and a generic SARIF consumer wouldn’t be able to reliably find the resources for all tools. That’s the root of the issue – if we allow external localized resource files
at all, then we have to tell SARIF consumers how to find them, or we lose interoperability. That was my original argument in favor of specifying the search order. From: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
And yes, the discipline you refer to is on the part of the tool author, as I said below: … external localized resource files are always associated with a particular version of the tool … the SARIF consumer will always find the same version
of the external localized resource file… That is, the tool author must never make changes to an external localized resource file without incrementing the version number. From:
sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) Rule id collisions occur because some tools use the same rule id to refer to a collection of logically related but distinct diagnostics. The spec gives an example. From: Michael Fanning <Michael.Fanning@microsoft.com>
Hello! I think we should probably take a closer look at the resources object in general. Resources now has a root level dictionary (messages) and an array (rules), an inconsistency
worth considering. We have discussed in the TC whether we should retain the resources probing mechanism now that we have developed the external files mechanism. As mentioned in the last TC, my intuition is that we’re getting a bit out of our wheelhouse with
the resources mechanism, specifying significant behaviors (related to locale/region, probing for files, etc.) that are outside the static analysis domain. That’s a general comment. My comment on your specific issue: I agree that our current design raises a concern, we’ve lost some useful coupling between a localized resources
file and a log (i.e., a stable resource name used as a key into a table) but this issue can be worked around with some discipline. That requirement for discipline, though, underscores a design weakness we’ve introduced. Can you or someone else recall for me why we believe rule id collisions are likely to occur? File name and logical name collisions are clear because a single tool + analysis
run may operate against targets that share these constructs. Presumably a tool ships a single, consistently named body of rules that apply to results generated. I can’t recall the scenario we had in mind for a collision in rule id (but trust that it turned
up). Jim, do you recall? Michael From:
sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) 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]