"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

sarif message