Subject: Full disclosure: editorial changes introduces normative statements
While updating some SARIF validation rules in the SDK, I found a couple of errors in the spec, related to the treatment of nested files. I corrected them at editorial discretion, even though the corrections introduce normative statements:
First: The description of the run.logicalLocations property (§3.13.12) contains this requirement:
If a nested logical location appears in the logicalLocations array, then the logicalLocations array SHALL also contain elements describing each of its parents, up to and including the top-level logical location.
I noticed that the description of the run.files property (§3.13.11) did not contain the corresponding statement, so I added it:
If a nested file appears in the files array, then the files array SHALL also contain elements describing each of its parents, up to and including the top-level file.
Second: We no longer need “nested file URIs” (for example, "file:///C:/output/SourceArchive.zip#/io/stream.c"). We used to use them as keys in the run.files dictionary, but now run.files is an array. The spec correctly says, in the description of the file.fileLocation property (§3.21.2):
(In our example, that would be "io/stream.c".) But we neglected to say that the same is true for all fileLocation objects – regardless of whether they occur within file objects. So I added this passage to the description of the fileLocation.uri property (§3.4.3):
If the fileLocation object represents a nested file, then uri SHALL specify a relative reference  expressing the path to the nested file within its container. In that case, the fileIndex property (§3.4.5) SHALL be present.
NOTE: The fileIndex property makes it possible to locate the parent of a nested file.