Change draft for #145 (logicalLocations object)

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

I pushed a change draft for Issue #145, “For symmetry, define a logicalLocation object”:

 

Documents/ChangeDrafts/Active/sarif-v2.0-issue-145-logicalLocation-object.docx

 

I will move its adoption at the TC meeting on May 2^nd.

 

For this change draft in particular, you do not want to read it with Full Markup. I suggest you read it with Simple Markup, and if you’re really curious what the changes were, switch temporarily to Full Markup – but you might regret it.

Despite the issue title (which I should change), we did not newly define a logicalLocation object. That object already existed. The actual design issue we wanted to address was that one of the properties that should have been in logicalLocation (namely, decoratedName) was defined on location instead. That simple observation led us to find other ways to improve the design. If you like, you can look at Issue #145 to see how our thinking on the design evolved.

One thing we discovered as we thought about this problem was that we did not need two separate properties location.fullyQualifiedLogicalName and location.logicalLocationKey. It turned out that location.fullyQualifiedLogicalName alone sufficed. Once we understood that, Michael recognized that likewise, you didn’t need both result.ruleId and result.ruleKey. Instead, result.ruleId by itself suffices.

 

Happy reading. Feel free to ask me any questions on this one (that’s always true, but I want to stress it for this issue in particular).

 

Thanks,
Larry