Subject: RE: tool.language considered unnecessary
It’s not strictly required.
The spec defines an algorithm for resource lookup:
“If you want fr-FR, look for a file named fr-FR.sarif-resources under tool.resourceLocation (now toolComponent.resourceLocation). If you can’t find it, look for fr.sarif-resources in the same place. If you still can’t find it, do whatever you can to find it – for example, prompt the user”.
tool.language defines a starting place for the resource lookup. But it’s not clear that’s what the end user wants. I don’t care if the log file says fr-FR, I still want the en-US messages. For my purposes, the lookup should start with my locale, not with whatever the log file happens to say.
There is one scenario, aside from the one I mentioned below, where tool.language might be useful. Suppose a tool supplies only French and Italian resources, and suppose they live on the web. Now I open a log file and I want to see resources for my locale, en-US. The lookup procedure fails: there is no file en-US.sarif-resources under resourceLocation. Now what should I do? If the log file specifies tool.language: fr-FR, I at least know that French is available, and maybe my high school French will help a little. Whereas if the log file doesn’t specify a language, I have no way to know what languages are available – they’re out on the web; it’s not like I can issue a “dir” command on the resource location.
Maybe this scenario, together with the one below, is enough to justify the property. Or maybe others can come up with other scenarios for it.
Isn’t that data required if a log file utilizes the localized resources look-up scheme? IOW, all possible strings are stripped from the log file in favor of external localized content. tool.language documents what resources to retrieve.
Motivation: Most tool object properties are moving to toolComponent, so we will have tool.driver of type toolComponent, and tool.extensions of type toolComponent. The only other property left on tool is language.
Question: The spec says that language is “the language of the messages produced by the tool”. If I can read them, I know what language they are. If I can’t read them, I don’t care what language they are (and I might ask my SARIF viewer to go find the tool’s en-US strings). Why do I need tool.language?
The only scenario I can think of is where a result management system used by an English-speaking engineering team consumes a log file with messages in fr-FR, and decides to help out by downloading the tool’s en-US strings.