Subject: RE: Change draft for #248: Associate file location with repo
Oh, and Iâm sorry â I keep saying âmy designâ, but actually the idea of linking a versionControlDetails to a fileLocation via a uriBaseId was Michaelâs.
Both my design and Jimâs accomplish that. The difference is that in my design, the link from a versionControlsDetails object to a fileLocation is purely a uriBaseId, whereas in Jimâs design, the link is a full-fledged fileLocation object (versionControlDetails.mappedTo). Jimâs point (as I understood it; see my inline commentary on his design in the issue) was that his design simplified life for the SARIF producer because the producer didnât need a separate uriBaseId for each repo.
Having said that, and having taken the time to write the change draft, Iâm now coming around to your point of view: that weâve traded producer convenience for consumer complexity. Each consumer has to implement that algorithm to get the right mapping.
The counter-argument is: âThere are lots more producers (tools) than consumers (viewers and result management systems).â So we should favor convenience for consumers. This is actually a design principle weâve followed in the past.
The counter-counter-argument is: âThis really only helps producers in the case where there are submodules. In other cases, you would generally have one uriBaseId per repo. Why are we complicating life for consumers, just for the sake of consumer convenience in one scenario, and not the most common scenario at that?â
One more thing: even though only consumers need to implement Jimâs algorithm, both producers and consumers need to read and understand it, because producers need to understand how to populate originalUriBaseIds and versionControlDetails.mappedTo in Jimâs design.
TL;DR: Iâm coming back around to preferring the simplicity of my design.
I am concerned at the difficult in understanding this proposal. I also am wondering whether we have clearly identified the goals of this design.
Hereâs the scenario that originally drove this request
That probably read snarkier than I intended 😊 Jimâs description is accurate and much more compact than it would have been if heâd expressed it without the symbols. Itâs just that readers of the spec will need some help to understand it.
I pushed a change draft for Issue #248: âVersion control details not strongly associated with resultsâ:
We will move its adoption at TC 29 on Wednesday December 12th.
We had previously proposed a design for this, but Jim objected and proposed what, after a careful reading, I think is a better one. The new change draft follows Jimâs design.
Jim, academic that he is 😊, expressed his mapping algorithm rather abstractly. Fortunately, I was also an academic in a former life, so I interspersed some comments into Jimâs description of his design, and extensively annotated his example in the text of the change draft. Please follow the example closely to make sure you know what Jim is proposing.