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