[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 [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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]