[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] RE: I don't think we need an "attachment" object any more
So attachments used to have regions which could be used to annotate a region in the attachment. If simplify to a file location, don’t we lose it?
The same file in the table could be annotated in separate ways, so we can use a unique file location to for this.
What has happened to the annotations that are associated with an attachment? Can you provide a more comprehensive view of the final type definitions you have in mind?
I’m sorry, I was so excited about this idea that I was inaccurate. conversionProvenance is of type physicalLocation (and physicalLocation = fileLocation + region), not of type attachment. And it’s the invocation object, not the run object, that has an attachments property.
But I still think replacing the attachment object with the file.description property is a good idea!
Also, I would add a new permittted value analysisToolLogFile in file.roles.
As you know, both run and result have a property attachments of type attachment. result also has conversionProvenance of type attachment. An attachment is nothing but a fileLocation plus a description. The spec says this about description:
An attachment object SHOULD contain a property named description whose value is a message object (§3.9) describing the role played by the attachment.
The “role”, huh? Be we just added a roles property to the file object! So perhaps the file object is also the natural place for description. Then we don’t need the attachment object, and instead we have:
I stumbled on this as I was starting to write the words for Issue #134, “conversion.analysisToolLogFileLocation should be an array”, which made me look at result.conversionProvenance and wonder why it was an attachment.
If we agree, I’d like to do this in the same change draft as the one I’m writing for #134, since they both touch result.conversionProvenance.