I created and pushed a change draft:
https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/Accepted/sarif-v2.0-issue-396-special-locations-display-base.docx I haven’t mentioned it for a while, but the provisional draft continues to be up to date with all the changes so far:
https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.docx The HTML version is also now up to date:
https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.htm This particular change draft has some formatting problems , which you can ignore because I fixed them in the provisional draft. You might find it easier just to look at the two new sections in the provisional draft : 3.14.16: run.specialLocations property 3.25: specialLocations object Please take a look, especially Jim . We still plan to open the CSD 2 ballot on Monday. Thanks, Larry From:
sarif@lists.oasis-open.org <
sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Saturday, April 27, 2019 9:08 AM To: OASIS SARIF TC Discussion List <
sarif@lists.oasis-open.org> Subject: [sarif] #396: "Suggesting file path display base to viewers": Revised proposal Importance: High After Jim presented this proposal, there was a lot of follow-on discussion with Jim, Michael, and me. All agreed that it is valuable to provide this hint to viewers; the discussion was about how to represent it: As a reserved property name DISPLAYBASE in run.originalUriBaseIds . As a property name SARIF_DISPLAYBASE in a reserved SARIF_ -prefixed "namespace" in run.originalUriBaseIds . As a new property run.displayBase . All of these had drawbacks: #1 requires a reserved name, and requires that name to be treated specially (not actually used as a uriBaseId value anywhere else in the log file). Also, it implies that if we added any other "special" values in the future, it would be a breaking change, since an implementer might have already used whatever value we chose. #2 also requires a reserved name that can't actually be used as a uriBaseId elsewhere in the log file. It has the advantage over #1 of allowing additional special values to be defined in a non-breaking way, at the cost of defining a mini-language on the property names. #3 doesn't have the drawbacks of #1 or #2, but if we define other special URIs in future, we'd have a proliferation of properties on the run object. @michaelcfanning and I propose this alternative: Define a property run.specialLocations with a single property displayBase whose value is an artifactLocation . In future, additional specially treated locations can be defined in a non-breaking way by defining new properties on run.specialLocations . It has these advantages: It doesn't require a reserved and specially treated uriBaseId value. It doesn't require a namespace on uriBaseId values. It allows new "special" locations to be defined in a non-breaking way. It avoids a proliferation of properties on the run object. It has this disadvantage: It requires a schema change to define the new object. @michaelcfanning and I are willing to take the pain of the schema change to get the other benefits. Thanks, Larry