[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Change draft for #248: Associate file location with repo
|
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. Larry From: Michael Fanning <Michael.Fanning@microsoft.com>
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
Michael From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) 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. From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) I pushed a change draft for
Issue #248: âVersion control details not strongly associated with resultsâ: Documents/ChangeDrafts/Active/sarif-v2.0-issue-248-versionControlProvenance-file-mapping.docx 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. Thanks, Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]