OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: recommendedArtifactDisplayBase


Can you explain further why one or more well-named uriBaseIds can’t help here?

 

Imagine a viewer that simply constructs its view according to the way that a producer has organized these constructs. If the producer is thoughtful about how it organizes this data and the name that it uses, a generic viewer could do a good job. This is a nice motivation for producers to help out.

 

The obvious possible complication is when there is a necessary decomposition of a URI into some uriBaseId + extra stuff, mandated by things like nesting repositories. On a cursory think, though, I can’t think of where this complexity interferes with the viewer function, it’s *helpful* to know how the repository nesting is structured.

 

The great flexibility of uriBaseIds over your suggestion is that you can provide more than one of them, rather than a single hint as you’ve suggested.

 

If you have time to send a more detailed example of what you have in mind, please do.

 

Play this mental game: if a SARIF producer created a uriBaseId named $(RecommendedBase) and set it to the actual recommended base in the originalUriBaseIds data, wouldn’t that effectively provide what you’re after? At the potential cost of constraining other use of the URI construction mechanism?

 

Sent from Mail for Windows 10

 


From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> on behalf of James Kupsch <kupsch@cs.wisc.edu>
Sent: Wednesday, April 24, 2019 2:24:10 PM
To: sarif@lists.oasis-open.org
Subject: [sarif] recommendedArtifactDisplayBase
 
Sorry for the late small proposal, but I've been thinking about a
generic SARIF viewer and how to display paths to a human.  In a viewer
it is nice to normalize the display for paths to be relative to a single
location, or to be absolute for location not contained within the single
location.

Without the viewer and the producer agreeing out of band on a uri, or a
baseUriId name to use, the viewer does not know how to base the results
for result display.

I propose adding a property name something like
recommendedArtifactDisplayBase to the run object with a value of type
artifactLocation.  Producers MAY set this to an appropriate value if
possible.  If set, consumers that display relative paths, SHOULD display
paths to relative to the recommendedArtifactDisplayBase if the path is
contained in the recommendedArtifactDisplayBase.  If it is not contained
in recommendedArtifactDisplayBase, viewer may display it as an absolute
path (or by some other appropriate mechanism).

Jim


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]