I’m not sure I agree with this distinction. I think the location concepts makes most sense when we expect a URI (particularly a file URI) that might have a non-deterministic root.
We don’t expect any of the things you’ve cited below to be rooted in a non-deterministic way (off an enlistment, for example). So on first blush I’d expect all these things to be URIs.
I think I’ve made this point before, though, and we still have locations here, so perhaps I’m forgetting a line of reasoning someone put forward that’s relevant?
From: <>
On Behalf Of Larry Golding (Comcast)
Sent: Tuesday, May 29, 2018 11:49 AM
To:
Subject: [sarif] "uri" vs. "location"
At TC #17, while discussing
Issue #163 (“Add result.workItemLocation”), I pointed out that some “URI-valued” properties are represented as strings, while others are represented as
fileLocation objects. I took an action to decide on a policy for deciding which type to use, and filed
Issue #175, “Decide on policy for fileLocation vs. URI,” where I wrote:
We have two URI-like properties that are represented by URI-valued strings:
·
tool.downloadUri
·
versionControlDetails.uri (the URI of the repo)
... while all the others (14 of them) are represented by fileLocation objects,
including:
·
result.workItemLocation
·
rule.helpLocation
Basically I've used fileLocation where
there are potentially "many" of something (work items, rules), and URI-valued strings where there's only one of something (tool download location, VCS repo).
Is this a valid distinction? Even if you can rationalize it, is it confusing? Should we use fileLocationeverywhere?
Having thought about this some more, I think the approach we’ve taken so far makes sense: If there are potentially many of something, use
fileLocation; if there’s only one of it, use a URI-reference-valued string.
I’m going to propose this at TC #19 (it’s too late to put it on the agenda for tomorrow’s TC #18).
Larry
