[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. Larry From: Michael Fanning <Michael.Fanning@microsoft.com>
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. From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) 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. Thoughts? Thanks, Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]