RE: #396: "Suggesting file path display base to viewers": Revised proposal

I created and pushed a change draft:

https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/Accepted/sarif-v2.0-issue-396-special-locations-display-base.docx

I haven’t mentioned it for a while, but the provisional draft continues to be up to date with all the changes so far:

https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.docx

The HTML version is also now up to date:

https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.htm

This particular change draft has some  formatting problems , which you can  ignore  because I fixed them in the provisional draft. You might find it easier just to look at the two new sections in the
provisional draft :

3.14.16:  run.specialLocations  property
3.25:  specialLocations  object

Please take a look,
especially Jim .  We still plan to open the CSD 2 ballot on Monday.

Thanks,
Larry
From:   <>  On Behalf Of  Larry Golding (Myriad Consulting Inc)

Sent:  Saturday, April 27, 2019 9:08 AM
To:  OASIS SARIF TC Discussion List <>
Subject:  [sarif] #396: "Suggesting file path display base to viewers": Revised proposal
Importance:  High

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