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):

If the file object represents a nested file … then
fileLocation
SHALL be present, and the value of its uri property
SHALL be a relative reference [RFC3986] expressing that path.

 

(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 [RFC3986] 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.

 

Thanks,

Larry