Change draft for #76 (encoding requirements) and #97 (text/binary file content)

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

I pushed a change for that addresses two issues, and also incorporates two more changes:

 

Issue #76: Clarify encoding requirements for properties that contain text from source files

Issue #97:  file object’s contents property

 

As part of #76, I also specified the encoding of the SARIF file itself, as I explained in email yesterday.

 

#97 is about being able to represent file content as either or both of readable text and binary bytes.

 

Now that we have a better understanding of file encoding, and a better representation of file content, I took the opportunity to improve the representation of the replacement object. Please see the changes starting at §3.32, “fix object”, and going on from there.

 

I made one other change that I think will not be controversial. Please see the changes in §3.14.4, “responseFiles” property. I changed this property from a dictionary (response file name => response file contents) to an array of fileLocation objects. My comment on that section explains why:

 

Everywhere else in the spec where we embed the entire contents of a file (for example the files that capture stdin/stderr/stdout, and attachment files) we specify the location of the file, and then leave it up to the run.files dictionary to embed the content. The invocation.responseFiles property was the only place we directly embedded the entire contents of a file anywhere other than the run.files dictionary.

I should have made this change when we introduced the fileLocation object.

 

The change draft is:

 

Documents/ChangeDrafts/Active/sarif-v2.0-issue-76-97-encoding.docx

 

I added this item to the Agenda that’s checked into the repo, and I will move for its adoption at the next TC meeting.

 

Thanks,

Larry