OASIS Static Analysis Results Interchange Format (SARIF) TC

Back to discussions
Expand all | Collapse all

RE: Change draft for #248: Associate file location with repo

  • 1.  RE: Change draft for #248: Associate file location with repo

    Posted 12-10-2018 17:51




    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>

    Sent: Monday, December 10, 2018 9:36 AM
    To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
    Subject: RE: Change draft for #248: Associate file location with repo


     
    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
     

    I have a SARIF log file and would like to recreate the enlistment locally in order to get source files that match the analysis I see an originalUriBase that points to the non-deterministic root of the enlistment I d like to find the version control details for this root and to sync to it locally.
     
    Michael


    From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org >
    On Behalf Of Larry Golding (Myriad Consulting Inc)
    Sent: Sunday, December 9, 2018 5:04 PM
    To: Larry Golding (Myriad Consulting Inc) < v-lgold@microsoft.com >; OASIS SARIF TC Discussion List < sarif@lists.oasis-open.org >
    Subject: [sarif] RE: Change draft for #248: Associate file location with repo


     
    That probably read snarkier than I intended



Related Content