$schema property and hardcoded URLs
maroneze opened this issue · 2 comments
In Sarif Viewer v3.1.1, it seems only hardcoded values for the $schema property are accepted. In particular, if I have a $schema with https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json, my SARIF files are loaded normally.
However, if I try a different value, such as https://json.schemastore.org/sarif-2.1.0.json, when loading the file, I get an error:
'report.sarif' was not loaded. Version '2.1.0' and schema 'https://json.schemastore.org/sarif-2.1.0.json' is not supported.
The OASIS specification says that:
3.13.3 $schema property
A sarifLog object MAY contain a property named $schema whose value is a string containing an absolute URI from which a JSON schema document [JSCHEMA01] describing the version of the SARIF format to which this log file conforms can be obtained.
If the $schema property is present, the JSON schema obtained from the specified URI SHALL describe the version of the SARIF format specified by the version property (§3.13.2).
NOTE 1: The purpose of the $schema property is to allow JSON schema validation tools to locate an appropriate schema against which to validate the log file. This is useful, for example, for tool authors who wish to ensure that logs produced by their tools conform to the SARIF format.
NOTE 2: The SARIF schema is available at https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json.
Currently, the URL indicated in the standard is unavailable: it returns an error 404. As mentioned in oasis-tcs/sarif-spec#498, the json.schemastore URL is a stable/hosted version of the schema.
Some tools actually try checking the URL, and the lack of the original URL is a problem for them; on the other hand, using the new URL prevents SARIF Viewer from opening the file.
It seems the only solution is to remove the $schema property entirely, in which case apparently SARIF Viewer does not try to validate anything, and accepts the file.
I wonder if it would be possible for SARIF Viewer to (1) support multiple URLs for the schema (at least one of them leading to an existing file); (2) somehow state more explicitly that the only supported schema value is the exact URL indicated in the standard, even if it no longer exists; or (3) accept the file even if it does not know the URL, with a warning about "not being able to verify the schema" or similar (this solution would at least make the same file compatible with both SARIF Viewer and other tools). The current behavior is not very intuitive and can lead to some confusing debugging sessions, and lack of interoperability of the same SARIF file.
hi @maroneze,
I believe the issue you reported is related to Sarif Viewer for VS Code. I cannot repro the issue in Sarif Viewer for VS.
I tried open a SARIF file with schema 'https://json.schemastore.org/sarif-2.1.0.json' using VS extension Sarif Viewer.
The viewer can still load the results in Error List although there is a warning says 'The type of schema applied to the document is not supported'.
This warning was generated by Visual Studio because the JSON schema version in the link is draft 7, which is not supported by VS yet according to https://developercommunity.visualstudio.com/t/support-json-schema-draft-06-draft-07/796216.
You can use the draft 4 version JSON schema at http://json.schemastore.org/sarif-2.1.0-rtm.5 instead to avoid the warning.
If the issue still exists, you may need transfer the issue to VS Code repository at https://github.com/Microsoft/sarif-vscode-extension.
Having never installed Visual Studio, I had incorrectly assumed that extensions were shared between VS and VS Code. Indeed you are right, the behavior is not the same in VS. I just installed SARIF Viewer 2022 (apparently released today) and it does not behave like the extension in VS Code. In fact, I don't even see the warning about "The type of scheme applied to the document is not supported". In any case, the extension does open the file and shows the results, which is the important part.
Thank you for pointing to the right repository, and sorry about the noise.