sarif — archive

[Laurence Golding]

After Jim presented this proposal, there was a lot of follow-on discussion with Jim, Michael, and me. All agreed that it is valuable to provide this hint to viewers; the discussion was about how to represent it: As a reserved property name  DISPLAYBASE  in  run.originalUriBaseIds . As a property name  SARIF_DISPLAYBASE  in a reserved  SARIF_ -prefixed "namespace" in  run.originalUriBaseIds . As a new property  run.displayBase . All of these had drawbacks: #1 requires a reserved name, and requires that name to be treated specially (not actually  used  as a  uriBaseId  value anywhere else in the log file). Also, it implies that if we added any other "special" values in the future, it would be a breaking change, since an implementer might have already used whatever value we chose. #2 also requires a reserved name that can't actually be used as a  uriBaseId  elsewhere in the log file. It has the advantage over #1 of allowing additional special values to be defined in a non-breaking way, at the cost of defining a mini-language on the property names. #3 doesn't have the drawbacks of #1 or #2, but if we define other special URIs in future, we'd have a proliferation of properties on the  run  object. @michaelcfanning  and I propose this alternative: Define a property  run.specialLocations  with a single property  displayBase  whose value is an  artifactLocation . In future, additional specially treated locations can be defined in a non-breaking way by defining new properties on  run.specialLocations . It has these advantages: It doesn't require a reserved and specially treated  uriBaseId  value. It doesn't require a namespace on  uriBaseId  values. It allows new "special" locations to be defined in a non-breaking way. It avoids a proliferation of properties on the  run  object. It has this disadvantage: It requires a schema change to define the new object. @michaelcfanning  and I are willing to take the pain of the schema change to get the other benefits. Thanks, Larry