OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sarif] Edits for the spec


Paul,

 

Thank you again for your careful reading. Iâve incorporated all necessary changes into the provisional draft. Here are my responses to your substantive concerns:

 

  • In Â3.4.4, artifactLocation.uriBaseId property, you commented:

    I seem to remember that if uri is relative and if uriBaseId is not present, then the uri should be resolved with respect to the directory in which the sarif file exists. Is that still the case? Some clarification of this would be useful here, or a reference to somewhere else where clarification is made.

    That interpretation applies in only one place: in Â3.15.2, externalPropertyFileReference.location property, which says:

 

If the externalized properties are persisted in a separate file, location SHALL be present. In that case, if the artifactLocation objectâs uri property (Â3.4.3) specifies a relative reference and its uriBaseId property (Â3.4.4) is absent, then uri SHALL be interpreted relative to the location of the root file.

That seemed like a reasonable default in this particular case: it wouldnât be surprising if an external property sat alongside its parent log file. In all other cases (for example, when the artifact is a source file, or a configuration file, or a tool binary, etc.), it did not seem to me that there was any reasonable default.

 

  • In Â3.26.5, location.annotations property, you commented (with regard to a sample):

    Did you mean these columns to refer to a particular range within the example string?

    Yes, and I got them wrong. I meant them to refer to the subexpression "(y + z)", so Iâve corrected them from (13, 19) to (9, 16).

  • In Â3.53.3, notification.message property, you commented (with regard to a note saying that notification.message would usually be plain text because it appears on the console):

    In CodeSonar, only the most basic notifications about command line errors go to the console. Many other notifications show up with formatting in the UI. Also, Iâve seen plenty of command line tools that use ansi codes to color the text output to the console. Iâd just as soon delete this note.

    You are right. I removed the note.

    (With regard to ANSI color code on the console, youâd have to drop down to HTML to represent that in Markdown, and the spec actually prohibits that â see Â3.11.4.2, âSecurity implicationsâ.)

 

Larry

 

-----Original Message-----
From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Monday, April 8, 2019 2:22 PM
To: Paul Anderson <paul@grammatech.com>; sarif@lists.oasis-open.org
Subject: RE: [sarif] Edits for the spec

 

Thank you Paul! Henny will be pleased to know that the two of you found many of the same typos 😊 I will respond to the substantive issues later today.

 

Larry

 

-----Original Message-----

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Paul Anderson

Sent: Monday, April 8, 2019 2:04 PM

To: sarif@lists.oasis-open.org

Subject: [sarif] Edits for the spec

 

Larry:

 

I went over the entire document in detail; my edits are in the attached.

They are mostly very superficial.

 

You are to be commended for doing such a fantastic job on this. The quality of this document is superb!

 

-Paul

 

--

Paul Anderson, VP of Engineering, GrammaTech, Inc.

531 Esty St., Ithaca, NY 14850

Tel: +1 607 273-7340 x118; https://nam06.safelinks.protection.outlook.com/?url="">

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]