[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] "uri" vs. "location"
Ouch, you just pointed out an issue. We defined uriBaseIds in part as a mechanism to allow a post-processing tool to elide non-deterministic information. If people simply use this mechanism to DRY out their URLs, they potentially break
their absolute URLs without providing an obvious way to restore them (as people can do for version controlled scenarios in some cases by pointing to a local enlistment). You have a case for
this being a useful distinction but it is a non-obvious one in the spec. I think my personal preference here is that it’s much cleaner to separate things we expect to be absolute (named xxxUri) vs. things we expect to be rebased (fileLocation). Yes, we lose the convenience of reducing log file size but I think
it’s a useful trade-off. Michael From: Larry Golding (Comcast) <larrygolding@comcast.net>
Yes, we have discussed it before. My counter-argument was that although we
invented “URI base ids” to improve determinism, they have the nice side effect of reducing repetition and file size, even for deterministic URIs. For example: { # A run object "uriBaseIds": { "WORKITEMS": "https://github.com/Microsoft/sarif-sdk/issues" # Deterministic, but nice to DRY out. }, "results": [ { "workItemLocation": { "uriBaseId": "WORKITEMS", "uri": "895" } } ] } That’s why I think “one/many” is an appropriate distinction. BUT! Even a singleton URI needs to be represented as a
fileLocation if it’s non-deterministic. At the moment, there is no example in the spec of a property that’s both a singleton and non-deterministic. But to guard against that possibility, I’m ok with stating the
guideline as:
Use fileLocation if the URI describes something of which there are potentially many per run (for example, a GitHub issue),
OR if the URI is non-deterministic (it might vary from machine to machine or from run to run). Use a URI string if the URI describes something of which there is only one per run,
AND is deterministic (for example, a GitHub repo). Note that there is no spec change involved here if we adopt this policy. If we adopt a different policy (one that requires us to change the type of an existing property),
then we need a spec change. Larry From: Michael Fanning <Michael.Fanning@microsoft.com>
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: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast) 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]