“sarif-fragment” is nice because it suggests “sarif-resources” as the extension for the language-specific resource files defined elsewhere in the spec. If “-sarif” is at the end of the extension, you end up with “resources-sarif” which
doesn’t read as well.
From: <>
On Behalf Of Michael Fanning
Sent: Wednesday, October 17, 2018 7:31 AM
To: 'OASIS SARIF TC Discussion List' <>
Subject: [sarif] 'externalFiles' to 'externalFragments'?
Larry and I were discussing a possible rename yesterday, just sanity checking this with the group. We were specifically noting that we require a naming convention to help distinguish ‘external’ files. The reason is that their only distinguishing
characteristic within the file is the $scheme property, which is optional (the version property matches a root/parent SARIF file).
And so a convention to name these files something like *.external.sarif would be useful. Alternately, of course, we could consider defining an entirely new extension, e.g., external-sarif.
When considering either a new extension or a file naming convention, it occurred to me that the use of the term ‘fragment’ would be clearer. And so I have two questions:
What would people think about using ‘externalFragments’ as a name rather than ‘externalFiles’? This would be minimally intrusive in the spec and lead to file names such as ‘example.fragment.sarif’,
which is clearer than ‘example.external.sarif’.
What mechanism should we prefer, a naming convention or a new extension? I,.e., ‘example.fragment.sarif’ or ‘example.fragment-sarif’? or even ‘example.sarif-fragment’ (which is entirely
readable)
Michael
